XSS、CSRF、JWT入门和知识总结

XSS攻击跨网站脚本（Cross-site scripting，通常简称为XSS或跨站脚本或跨站脚本攻击）是一种网站应用程序的安全漏洞攻击，是代码注入的一种。 它允许恶意用户将代码注入到网页上，其他用户在观看网页时就会受到影响。这类攻击通常包含了HTML以及用户端脚本语言。XSS 利用的是用户对指定网站的信任。

XSS攻击的类型XSS 攻击可以分成两种，反射性 XSS / 存储型 XSS。前者是需要用户触发的 XSS， 针对当前用户的攻击行为。而后者存储型 XSS 则更为严重，一旦攻击代码被保存， 所有访问被攻击的页面，都会触发用户被攻击行为。

攻击手段和目的盗用cookie，获取敏感信息。利用植入Flash，通过crossdomain权限设置进一步获取更高权限；或者利用Java等得到类似的操作。利用iframe、frame、XMLHttpRequest或上述Flash等方式，以（被攻击）用户的身份执行一些管理动作，或执行一些一般的如发微博、加好友、发私信等操作。利用可被攻击的域受到其他域信任的特点，以受信任来源的身份请求一些平时不允许的操作，如进行不当的投票活动。在访问量极大的一些页面上的XSS可以攻击一些小型网站，实现DDoS攻击的效果。

防御措施：过滤特殊字符，在许多语言中可以直接使用工具类进行过滤。使用 HTTP 头指定类型

CSRF攻击跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。CSRF 利用的是网站对用户网页浏览器的信任。

攻击示例假如银行网站examplebank用以执行转账操作的URL地址如下： http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName
恶意攻击者可以在自己的网站A放置如下代码： <img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">如果有账户名为Alice的用户访问了恶意站点，而她之前刚访问过银行不久，登录信息尚未过期，那么她就会损失1000资金。
这种恶意的网址可以有很多种形式，藏身于网页中的许多地方。此外，攻击者也不需要控制放置恶意网址的网站。例如他可以将这种地址藏在论坛，博客等任何用户生成内容的网站中。这意味着如果服务器端没有合适的防御措施的话，用户即使访问熟悉的可信网站也有受攻击的危险。透过例子能够看出，攻击者并不能通过CSRF攻击来直接获取用户的账户控制权，也不能直接窃取用户的任何信息。他们能做到的，是欺骗用户浏览器，让其以用户的名义执行操作。

防御措施：①检查Referer字段HTTP头中有一个Referer字段，这个字段用以标明请求来源于哪个地址。在处理敏感数据请求时，通常来说，Referer字段应和请求的地址位于同一域名下。以上文银行操作为例，Referer字段地址通常应该是转账按钮所在的网页地址，应该也位于www.examplebank.com之下。而如果是CSRF攻击传来的请求，Referer字段会是包含恶意网址的地址，不会位于www.examplebank.com之下，这时候服务器就能识别出恶意的访问。
这种办法简单易行，工作量低，仅需要在关键访问处增加一步校验。但这种办法也有其局限性，因其完全依赖浏览器发送正确的Referer字段。虽然http协议对此字段的内容有明确的规定，但并无法保证来访的浏览器的具体实现，亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器，篡改其Referer字段的可能。
添加校验token
②由于CSRF的本质在于攻击者欺骗用户去访问自己设置的地址，所以如果要求在访问敏感数据请求时，要求用户浏览器提供不保存在cookie中，并且攻击者无法伪造的数据作为校验，那么攻击者就无法再执行CSRF攻击。这种数据通常是表单中的一个数据项。服务器将其生成并附加在表单中，其内容是一个伪乱数。当客户端通过表单提交请求时，这个伪乱数也一并提交上去以供校验。正常的访问时，客户端浏览器能够正确得到并传回这个伪乱数，而通过CSRF传来的欺骗性攻击中，攻击者无从事先得知这个伪乱数的值，服务器端就会因为校验token的值为空或者错误，拒绝这个可疑请求。

使用JWT进行鉴权
关于JWT如何生成使用请查看http://www.cnblogs.com/xiekeli/p/5607107.html
下面我们从一个实例来看如何运用JWT机制实现认证：登录第一次认证：第一次登录，用户从浏览器输入用户名/密码，提交后到服务器的登录处理的Action层（Login Action）；Login Action调用认证服务进行用户名密码认证，如果认证通过，Login Action层调用用户信息服务获取用户信息（包括完整的用户信息及对应权限信息）；返回用户信息后，Login Action从配置文件中获取Token签名生成的秘钥信息，进行Token的生成；生成Token的过程中可以调用第三方的JWT Lib生成签名后的JWT数据；完成JWT数据签名后，将其设置到COOKIE对象中，并重定向到首页，完成登录过程；



请求认证基于Token的认证机制会在每一次请求中都带上完成签名的Token信息，这个Token信息可能在COOKIE中，也可能在HTTP的Authorization头中；


 过程解析：客户端（APP客户端或浏览器）通过GET或POST请求访问资源（页面或调用API）；认证服务作为一个Middleware HOOK 对请求进行拦截，首先在cookie中查找Token信息，如果没有找到，则在HTTP Authorization Head中查找；如果找到Token信息，则根据配置文件中的签名加密秘钥，调用JWT Lib对Token信息进行解密和解码；完成解码并验证签名通过后，对Token中的exp、nbf、aud等信息进行验证；全部通过后，根据获取的用户的角色权限信息，进行对请求的资源的权限逻辑判断；如果权限逻辑判断通过则通过Response对象返回；否则则返回HTTP 401；

参考：https://juejin.im/entry/5934ca350ce4630057235f3dhttp://www.cnblogs.com/xiekeli/p/5607107.html