XSS注入的防护

XSS注入的本质就是: 某网页中根据用户的输入, 不期待地生成了可执行的js代码, 并且js得到了浏览器的执行. 意思是说, 发给浏览器的字符串中, 包含了一段非法的js代码, 而这段代码跟用户的输入有关.

常见的XSS注入防护, 可以通过简单的 htmlspecialchars(转义HTML特殊字符), strip_tags(清除HTML标签) 来解决, 但是, 还有一些隐蔽的XSS注入不能通过这两个方法来解决, 而且, 有时业务需要不允许清除HTML标签和特殊字符. 下面列举几种隐蔽的XSS注入方法:

IE6/7 UTF7 XSS 漏洞攻击

隐蔽指数: 5 伤害指数: 5

这个漏洞非常隐蔽, 因为它让出现漏洞的网页看起来只有英文字母(ASCII字符), 并没有非法字符, htmlspecialchars 和 strip_tags 函数对这种攻击没有作用. 不过, 这个攻击只对 IE6/IE7 起作用, 从 IE8 起微软已经修复了. 你可以把下面这段代码保存到一个文本文件中(前面不要有空格和换行), 然后用 IE6 打开试试(没有恶意代码, 只是一个演示):

+/v8 +ADw-script+AD4-alert(document.location)+ADw-/script+AD4-

最容易中招的就是 JSONP 的应用了, 解决方法是把非字母和数字下划线的字符全部过滤掉. 还有一种方法是在网页开始输出空格或者换行, 这样, UTF7-XSS 就不能起作用了.

因为只对非常老版本的 IE6/IE7 造成伤害, 对 Firefox/Chrome 没有伤害, 所以伤害指数只能给 4 颗星.

不正确地拼接 JavaScript/JSON 代码段

隐蔽指数: 5 伤害指数: 5

Web 前端程序员经常在 PHP 代码或者某些模板语言中, 动态地生成一些 JavaScript 代码片段, 例如最常见的:

var a = '<?php echo htmlspecialchars($name); ?>';

不想, $name 是通过用户输入的, 当用户输入 a’; alert(1); 时, 就形成了非法的 JavaScript 代码, 也就是 XSS 注入了.

在解决问题之前, 我们要思考问题的本质是什么? 本质在于程序员可以用字符串来控制整个世界, 却没有用正确的方法来生成正确的字符串, 而是采用了功能强大且原始的”手工字符串拼接”.

只需要把上面的代码改成:

var a = <?php echo json_encode($name); ?>;

去掉单引号, 利用 PHP 的 json_encode() 函数来生成表示字符串的字符串. 这样做是因为, 最好用 json_encode() 函数来生成所有的 JSON 串, 而不要试图自己去拼接. 程序员总是犯这样的错误: 自己去解析 HTTP 报文, 而不是用现成的成熟的库来解析. 用 json_encode() 的好处还在于, 即使业务要求”我要保留单引号”时, XSS注入也可以避免.

隐蔽指数最高级, 伤害所有的通用浏览器. 这种 XSS 注入方式具有非常重要的参考意义.

最后, 根据工作中的经验, 以及我自己和别人犯过的错, 我总结出一个定理: 没有一劳永逸的单一方法可以解决所有 XSS 注入问题.

有用的经验:

输出 HTML 代码时 htmlspecialchars

输出 JavaScript 代码时 json_encode

输入过滤应该用于解决业务限制, 而不是用于解决 XSS 注入(与严进宽出的原则相悖, 所以本条值得讨论)

讨论:

上文提到的经验第3条, 是一种”宽进严出”的原则, 和”严进宽出”原则是相悖的. 其实, 我认为不应该把”严进宽出”作为一条伪真理, 好像除了它其它的说法都不对了似的. “宽进严出”和”严进宽出”应该具有完全相等的地位, 根据实现的成本进行取舍.

例如, 用户的名字可以采用”严进宽出”原则, 不允许用户填写单引号, 大于号小于号等. 但是用户的签名呢? 难道就不能填单引号? 如果要走极端, 想找出一种银弹, 那么我能想到的就是对所有的输入一律进行 htmlspecialchars 和 json_encode(且不说解决不了 utf7-xss).

其实, XSS 注入的解决应该是和输出端相关的. 当需要输出到文本文件时, 过滤和转义都是无必要的. 当输出到 HTML 渲染引擎时, json_encode 是无必要的. 当输出到 JS 引擎时, htmlspecialchars 是无必要的.

本栏目更多精彩内容:http://www.bianceng.cnhttp://www.bianceng.cn/Network/Security/

以上是小编为您精心准备的的内容,在的博客、问答、公众号、人物、课程等栏目也有的相关内容,欢迎继续使用右上角搜索按钮进行搜索字符串
, 代码
, xss
, 输出
, html注入
, js注入问题
, json_encode
, htmlspecialchars
, 解决注入
, 注入防护大全(二)
, 注入防护大全
, js注入漏洞
, json中的特殊字符
xss漏洞修复
sql注入和xss的区别、xss注入、xss注入代码、xss sql注入、xss注入攻击,以便于您获取更多的相关知识。

时间: 2024-10-06 03:42:01

XSS注入的防护的相关文章

java web 防止xss注入

Java Web中如何防止xss 注入呢? 首先讨论第一个问题:存到数据库中的是转码之后的还是转码之前的? 转码之后: 转码之前:   结论是:存到数据库中的就是转码之前的.为什么呢? 因为xss 攻击只存在PC web端,如果数据库中存储的就是转码之后的,那么手机app显示出来不就有问题了么?   所以最终的做法就是在PC web端 转码: 转码方法: Js代码   escape= function (str) {               str = str ? str : '';    

xss-SpringMVC如何有效的防止XSS注入?

问题描述 SpringMVC如何有效的防止XSS注入? 通过度娘找到一个方案,新增一个XSSRequestWrapper来重写request对象的getParameter方法,过滤参数中的容易引起xss漏洞的字符,但实际对于multipart-data类型的表单提交并不起作用呢.因为项目已经开发的差不多了,用拦截器肯定是比较简单的.如果每个地方都加一下这些htmlEscape那太麻烦力. 解决方案 springmvc 防止XSS攻击springmvc 防止XSS攻击 解决方案二: 谢谢你,小N,

java中SpringMVC中@PathVariable注解的XSS注入问题

 XSS注入算是一个很常见的问题,其实解决起来并不难,但是有很多需要注意的地方,这里做一个完整的解决方案.    Java中常见的解决方案是继承HttpServletRequestWrapper,然后重载getParameter.getHeader等方法.但是要注意到文件上传是不走HttpServletRequestWrapper的,所有还需要解决文件上传时的xss问题.如果用SpringMVC,那么直接继承CommonsMultipartResolver即可. 如果使用了url中部分path(

如何使用Burp Suite模糊测试SQL注入、XSS、命令执行漏洞

本文讲的是如何使用Burp Suite模糊测试SQL注入.XSS.命令执行漏洞,今天我将使用打包的套件攻击工具对bwapp应用程序进行模糊测试,手动执行此测试是一个耗时的时间,可能对任何一个渗透性测试的安全人员来说都是无聊的过程. 模糊测试在软件测试中起着至关重要的作用,它是一种工具,用于通过将一组称为模糊的部分地址输入注入到要测试的应用程序的程序中来查找错误,错误,故障. 漏洞检查工具采用文件格式的结构输入来区分有效和无效的输入.漏洞检查工具最适合识别sql注入,缓冲区溢出,xss注入和OS命

Yii框架防止sql注入,xss攻击与csrf攻击的方法_php实例

本文实例讲述了Yii框架防止sql注入,xss攻击与csrf攻击的方法.分享给大家供大家参考,具体如下: PHP中常用到的方法有: /* 防sql注入,xss攻击 (1)*/ function actionClean($str) { $str=trim($str); $str=strip_tags($str); $str=stripslashes($str); $str=addslashes($str); $str=rawurldecode($str); $str=quotemeta($str)

整理php防注入和XSS攻击通用过滤_php技巧

对网站发动XSS攻击的方式有很多种,仅仅使用php的一些内置过滤函数是对付不了的,即使你将filter_var,mysql_real_escape_string,htmlentities,htmlspecialchars,strip_tags这些函数都使用上了也不一定能保证绝对的安全. 那么如何预防 XSS 注入?主要还是需要在用户数据过滤方面得考虑周全,在这里不完全总结下几个 Tips 1. 假定所有的用户输入数据都是"邪恶"的 2. 弱类型的脚本语言必须保证类型和期望的一致 3.

xss 和 csrf攻击详解

在那个年代,大家一般用拼接字符串的方式来构造动态 SQL 语句创建应用,于是 SQL 注入成了很流行的攻击方式.在这个年代, 参数化查询 已经成了普遍用法,我们已经离 SQL 注入很远了.但是,历史同样悠久的 XSS 和 CSRF 却没有远离我们.由于之前已经对 XSS 很熟悉了,所以我对用户输入的数据一直非常小心.如果输入的时候没有经过 Tidy 之类的过滤,我一定会在模板输出时候全部转义.所以个人感觉,要避免 XSS 也是很容易的,重点是要"小心".但最近又听说了另一种跨站攻击 C

防止SQL语句注入攻击总结

-----解决方案-------------------------------------------------------- 过滤URL中的一些特殊字符,动态SQL语句使用PrepareStatement.. ------解决方案-------------------------------------------------------- 注入的方式就是在查询条件里加入SQL字符串. 可以检查一下提交的查询参数里是否包含SQL,但通常这样无益. 最好的办法是不要用拼接SQL字符串,可以用

防御&amp;捕获XSS漏洞利器之CSP

最近在整理项目组的服务器日志,从海量信息中查找有攻击嫌疑的用户.发现了千奇百怪的攻击手法,不过大部分都是SQL与XSS注入,这里说几个好玩的. 伪造HTTP_X_FORWARDED_FOR信息 HTTP_X_FORWARDED_FOR = 127.0.0.1', select(0)from(select(sleep(3)))v', 15.19.86.28 普通情况下我们获取到的IP型如 "\$ip = $_SERVER('HTTP_X_FORWARDED_FOR')" ,直接存入数据库