Web安全摘录

上周看了这本关于web安全的书。写下摘录:

* 同源策略,限制了来自不同源的document或脚本,对当前document读取或设置某些属性。影响源的因素有:host,ip,子域名,端口,协议;对于当前页面来说,页面内存放js文件的域并不重要,重要的是加载js页面所在的域是什么

* phishtank.com提供恶意网址黑名单,google也提供 safebrowsing api

* IE打开网页时,同是https协议,为什么有的地址栏的背景能标成绿色,有的不是。标成绿色的是因为网站采用了EV SSL证书。(Extended Validation SSL Certificate)

* 对重要的cookie设置httponly标识,防止cookie劫持

* <base>标签可以出现在页面上的任何地方,并作用于位于该标签之后的所有标签。攻击者如果在页面中插入了<base>标签,就可以通过在远程服务器上伪造图片,链接或脚本,劫持当前页面中的所有使用“相对路径”的标签。所以在涉及xss安全方案时,一定要过滤掉这个非常危险的标签

* window.name因为在window下,不在document下,因此不受同源策略的限制。攻击者利用这个对象,可以实现跨域,跨页面传递数据。

* 突破xss字符数量限制执行任意js代码:http://secinn.appspot.com/pstzine/read?issue=3&articleid=4

* Apache Expect Header XSS,影响版本有apache server 1.3.34,2.0.57,2.2.1

* Flash出了allowScriptAccess外,allowNetworking也非常关键,这个参数能控制flash与外部网络进行通信。它有三个可选值:all,允许使用所有的网络通信,也是默认值;internal,flash不能与浏览器通信,如navigateToURL,但是可以调用其它的api;none,禁止任何的网络通信。一般建议此值设置为none或internal

* SWFIntruder,检测产生在flash里的xss漏洞。

* Javascript Encode, owasp esapi:https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API , https://www.owasp.org/index.php/ESAPI_JavaScript_Readme

* 对于浏览器来说,htmlparser会优先于js parser执行,所以解析过程是,被htmlencode的字符先被解码,然后执行js事件。

* 防御xss:1)在html标签中输出,防御方法是对变量使用HtmlEncode 。2)在HTML属性中输出,防御:使用HtmlEncode 。 3)在<script>标签中输出,防御使用JavascriptEncode 。4)在css中输出,使用owasp esasi中的encodeForCSS()函数 5)在地址中输出,使用URLEncode

* 处理富文本:过滤富文本时,“事件”应该被严格禁止。使用白名单,避免使用黑名单。尽可能的禁止用户自定义css与style

* AntiSamy是目前最好的xss filter。https://www.owasp.org/index.php/Antisamy 提供.net和java版本,python版本还在beta

* 防止dom based xss:以下几个地方是js输出到html页面的必经之路,需要关注这几个函数的参数,是否可以被用户控制。1) document.write() 。2)document.writeln() 。3)xxx.innerHTML=  4)xxx.outerHTML = 5)innerHTML.replace 6) document.attacheEvent   7) window.attachEvent  8) document.location.replace()  9) document.location.assign()

* cookie分为两种,session cookie,又称临时cookie;3rd-party cookie,又称本地cookie。两者的区别在于,3rd-party cookie是服务器在set-cookie时指定了expire时间,只有到了expire时间后cookie才会失效,所以这种cookie会保存在本地;而session cookie则没有指定expire时间,所以浏览器关闭后,session cookie就失效了。

* IE出于安全考虑,默认禁止了浏览器在<img> <iframe> <script> <link> 等标签中发送第三方cookie;在ff中,默认策略是允许发送第三方cookie的

* 如果网站返回给浏览器的http头中包含有怕p3p头,则在某种程度上来说,将允许浏览器发送第三方cookie。在IE下即使是<iframe> <script> 等标签也将不再拦截第三方cookie的发送

* CSRF Token的目的不是为了防止重复提交,所以为了使用方便,可以允许在一个用户的有效生命周期内,在Token消耗掉前都使用同一个Token。但是如果用户已经提交表单,则这个Token已经消耗掉,应该再次重新生成一个新的Token

* Clickjacking,通常可以写一段js代码,以禁止iframe的嵌套,这种方法叫frame busing。攻击frame busing的paper: http://seclab.stanford.edu/websec/framebusting/framebust.pdf

* HTTP头,X-Frame-Options ,可选值有DENY,SAMEORIGIN,ALLOW-FROM [origin],当为DENY时,浏览器会拒绝当前页面加载任何frame页面;若为SAMEORIGIN,则frame页面的地址只能为同源域名下的页面;若为ALLOW-FROM,则可以定义允许frame加载的页面地址

* HTML5 Security Cheatsheet :  http://code.google.com/p/html5security/ (未来html5 攻防的主战场,很可能会发生在移动互联网上)

* 因为使用宽字符带来的mysql语句转义的问题(\和前一个字符连在一起,组成其它字符,从而使\失效)。要解决这种问题,需要统一数据库,操作系统,web应用所使用的字符集,以避免各层对字符的理解存在差异。统一设置为UTF-8是个很好的方法。

* CRLF注入,在http协议中,http头是通过\r\n来分隔的,因此如果服务器端没有过滤\r\n,而又把用户输入的数据放在http头中(例如cookie),则有可能导致安全隐患。这种在http头的CRLF注入,又可以称为http response splitting 。这种危害甚至比XSS还要大,因为它破坏了http协议的完整性。对抗CRLF的方法很简单,只需要处理好\r\n这两个保留字符即可,尤其是那些使用“换行符”作为分隔符的应用。

* 上传文件可执行漏洞。在apache 1.x,2.x中,对文件名的解析就存在以下特性。apache对于文件名的解析是从后往前解析的,直到遇见一个apache认识的文件类型为止。比如phpshell.php.rar.rar.rar,因为apache不认识rar这个文件类型,所以会一直遍历后缀到.php,然后认为这是一个php类型的文件

* 处理redirect_url域的domain

* 防御文件上传漏洞实践:文件上传的目录设置为不可执行;判断文件类型;使用随机数该写文件名和文件路径;单独设置文件服务器的域名

* 认证是authentication,授权是authorization,认证的目的是为了认出用户是谁,而授权的目的是为了决定用户能够做什么。

* Session id可以存加密后的cookie(我记得flask框架里就是用的cookie based session),这样的session如何过期呢?很多应用都是利用cookie的expire标签来控制session的失效时间,这就给了攻击者可乘之机。Cookie的expire时间是完全可以由客户端控制的,篡改这个时间,使之永久有效,就有可能获得一个用户就有效的session

* 最好的xss防御方案,在不同的场景需要使用不同的编码函数,如果只使用HtmlEncode,则很可能会被攻击者绕过。(希望web的模板框架里自带filter就好了,比如现在jinja的escape只是html escape,还可以提供js escape和css escape,url escape等函数)

* mod_qos是apache的一个module,它可以帮助缓解应用层DDOS攻击。mod_evasive也有类似效果

* php内核是由c语言实现的,因此使用了c语言中的一些字符串处理函数。在连接字符串时,0字节(\x00)将作为字符串结束符。所以,如果攻击者通过web输入 ../../etc/passwd%00.php可能会读取到/etc/passwd

* web server配置安全,检查apache安全的第一件事,就是检查apache的module安装情况,根据“最小权限”原则,应该尽可能地减少不你要的module,对于要使用的module,则检查其对应版本是否存在已知的安全漏洞。不要让apache以root或者admin身份运行

* 网站设计功能时,不要暴露用户账号,显示时只显示用户昵称

* web安全扫描器:w3afskipfish(google使用的web安全扫描器)

3 comments:

  1. www.sumbriro.com

    This is a very good tip particularly to those fresh to the blogosphere.
    Brief but very accurate information… Appreciate
    your sharing this one. A must read article!

Leave a Reply

Your email address will not be published. Required fields are marked *