1.前端攻击形式：XSS攻击、append的利用、CSRF攻击（跨站请求伪造）
| 序号 | 名称 | 攻击形式 | 危害 | 防治方法 | 备注 |
|---|---|---|---|---|---|
| 1 | XSS攻击 | 允许恶意web用户将代码植 入到提供给其它用户使用的页面中。比如这些代码包括HTML代码和客户端脚本。攻 击者利用XSS漏洞旁路掉访问控制——例如同源策略(same origin policy) | 盗取各类用户账号、控制企业敏感数据、盗取企业资料、非法转账、发送邮件、控制受害者机器向其他网站发起攻击等 | 将前端输出数据进行转义，左右尖括号‘><’ ，会被转义为html字符实体，不会被当成标签来解析 | |
| 1.1 | append的利用 | 利用jquery会在将append元素变为fragment的时候，找到其中的script标签，再使用eval执行一遍。jquery的append使用的方式也是innerHTML。而innerHTML是会将unicode码转换为字符实体的 | |||
| 1.2 | 利用img标签的onerror事件 | 在onerror上传入js代码 | |||
| 2 | CSRF攻击（跨站请求伪造） | 利用用户session尚未过期，浏览器的cookie中含有用户认证信息的漏洞 | 攻击者盗以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。 | (1)、要合理使用post与get ; （2）、最简单的办法就是加验证码，这样除了用户，黑客的网站是获取不到用户本次session的验证码的。但是这样也会降低用户的提交体验;（3）、在用访问的页面中，都种下验证用的token，用户所有的提交都必须带上本次页面中生成的token，这种方式的本质和使用验证码没什么两样，但是这种方式，整个页面每一次的session，使用同一个token就行，很多post操作，开发者就可以自动带上当前页面的token。如果token校验不通过，则证明此次提交并非从本站发送来，则终止提交过程。如果token确实为本网站生成的话，则可以通过 | 帮助理解CSRF攻击原理的例子：受害者 Bob 在银行有一笔存款，通过对银行的网站发送请求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可以使 Bob 把 1000000 的存款转到 bob2 的账号下。通常情况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的 session，并且该 session 的用户 Bob 已经成功登陆。 黑客 Mallory 自己在该银行也有账户，他知道上文中的 URL 可以把钱进行转帐操作。Mallory 可以自己发送一个请求给银行：http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。但是这个请求来自 Mallory 而非 Bob，他不能通过安全认证，因此该请求不会起作用。 这时，Mallory 想到使用 CSRF 的攻击方式，他先自己做一个网站，在网站中放入如下代码： src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，并且通过广告等诱使 Bob 来访问他的网站。当 Bob 访问该网站时，上述 url 就会从 Bob 的浏览器发向银行，而这个请求会附带 Bob 浏览器中的 cookie 一起发向银行服务器。大多数情况下，该请求会失败，因为他要求 Bob 的认证信息。但是，如果 Bob 当时恰巧刚访问他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有 Bob 的认证信息。这时，悲剧发生了，这个 url 请求就会得到响应，钱将从 Bob 的账号转移到 Mallory 的账号，而 Bob 当时毫不知情。等以后 Bob 发现账户钱少了，即使他去银行查询日志，他也只能发现确实有一个来自于他本人的合法请求转移了资金，没有任何被攻击的痕迹。而 Mallory 则可以拿到钱后逍遥法外。 |
| 3 | 网络劫持攻击 | ||||
| 4 | 控制台注入代码 | ||||
| 5 | 钓鱼 |
我们平时开发要注意的：
- 开发时要提防用户产生的内容，要对用户输入的信息进行层层检测要注意对用户的输出内容进行过滤(进行转义等)重要的内容记得要加密传输(无论是利用https也好，自己加密也好)
- get与post请求，要严格遵守规范，不要混用，不要将一些危险的提交使用jsonp完成。
- 对于URL上携带的信息，要谨慎使用。心中时刻记着，自己的网站哪里可能有危险。
网友评论