想当黑客?是的,基本每个程序员都有一颗相当黑客的心。从【黑客帝国】再到【欧洲攻略】,Hackers总是在黑暗中微笑,慢慢的侵蚀着互联网,侵蚀着他想要去的地方,获取别人的数据库,获取自己想要的信息,是不是帅到不讲武德。
但是,我们身为公司的员工,我们有义务和责任保护公司的信息安全,这时候,我们可能有需要和黑客作斗争,化身为正义的天神,与黑暗中那个微笑的男人征战。
所以说,这篇文章我想告诉大家前端黑客是如何操作的以及在公司我们如何保护好项目不受侵犯。
1.跨站脚本(XSS)
攻击
全称:Cross Site Script(跨站脚本)
为了与层叠样式表css区分,将跨站脚本简写为XSS
危害:盗取用户信息、钓鱼、制造蠕虫等。
概念:黑客通过“HTML注入”篡改了网页,插入了恶意脚本,从而在用户在浏览网页时,实现控制用户浏览器行为的一种攻击方式。
黑客可以利用xss盗取用户的cookie,有了用户的cookie,可以以用户的身份来正常访问站点。
XSS属于客户端代码注入,通常注入代码是JavaScript。区别于命令注入,SQL注入属于服务端代码注入。
简单的来说,就是在网页提供给用户输入的地方写入代码。
XSS分为三种类型:反射型,存储型,Dom型。
**反射型:**一般来说这种类型的XSS,需要攻击者提前构造一个恶意链接,来诱使客户点击,比如这样的一段链接:
www.abc.com/?params=<script>alert(/xss/)</script>
**存储型:**这种类型的XSS,危害比前一种大得多。比如一个攻击者在论坛的楼层中包含了一段JavaScript代码,并且服务器没有正确进行过滤输出,那就会造成浏览这个页面的用户执行这段JavaScript代码。
**DOM XSS:**这种类型则是利用非法输入来闭合对应的html标签。比如,有这样的一个a标签:
<a href='$var'></a>
乍看问题不大,可是当$var的内容变为 ’ οnclick=’alert(/xss/) //,这段代码就会被执行。
实战:
这里我们讲的是Dom XSS,这是一个网页源码:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>XSS原理分析</title>
</head>
<body>
<form action="" method="get">
<input type="text" name="xss_input"><input type="submit">
</form>
<hr>
<?php
$xss = $_GET['xss_input'];
echo '请输入您的payload<br>'.$xss;
?>
</body>
</html>
界面是这样的:
![](https://i-blog.csdnimg.cn/blog_migrate/b918e36d6bc56d7f78a33159a47c0dcb.png)
我们首先输入123,看看能得到什么结果:
![](https://i-blog.csdnimg.cn/blog_migrate/bb763153acbc47ed53da89bec3bf2ce7.png)
去看看源码:
![](https://i-blog.csdnimg.cn/blog_migrate/ef20723b37566af865e0e692f6dba72a.png)
我们输入的字符串被原封不动输出了,这样的话,如果我们将123替换成bird 也会被原封不动的输出,由于alert()函数的功能是弹出对话框,那么也就是说我们输入上面的语句就会弹框,现在来看看
下面是输入bird 得到的页面:
![](https://i-blog.csdnimg.cn/blog_migrate/5d5f9e08cbccc8f9c8d97ff874c186c5.png)
果不其然真的弹框了,这就说明这个web页面存在XSS漏洞
再去看看源码:
![](https://i-blog.csdnimg.cn/blog_migrate/d8a14ea8599f20325aa26aa9903625ce.png)
防御
对用户的输入进行转义,即可解决XSS。
但是我们现在都是用框架进行开发,例如Vue,React,angular,而XSS常是基于DOM的,而框架很少去操作Dom,并且框架底层也对XSS做了一些防范。
2.跨站请求伪造(CSRF)
攻击
全称:Cross-site request forgery(跨站请求伪造)
危害:个人隐私泄露以及财产安全。
概念:攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作(如发邮件,发消息,甚至财产操作如转账和购买商品)。由于浏览器曾经认证过,所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞:简单的身份验证只能保证请求发自某个用户的浏览器,却不能保证请求本身是用户自愿发出的。
实战:
这里有一个网站,自带账号和密码,点击登录即可,你可以在文章下面发表一条评论并且记住自己的用户名。
![](https://i-blog.csdnimg.cn/blog_migrate/34299561e95e5216cf9ccc4140a9279e.png)
当你点击这个链接,你会发现刚才的网站你的账户名又发表了一个新的留言,这个就是CSRF。
用户在网站登录后,这个网站服务端会在 Cookie 中会放一个凭证,这个凭证是后端用来验证用户身份的。在发评论的时候,提交评论的请求会带上这个凭证,后端通过判断这个凭