Web前端开发中的黑客技术以及安全技术详细版
- 1.跨站脚本(XSS)
-
- 1.1 概念
- 1.2 分类
-
- 1.2.1 反射型
- 1.2.2 存储型
- 1.2.3 DOM XSS
- 1.3 实例
- 1.4 解决方案
- 2.跨站请求伪造(CSRF)
-
- 2.1 概念
- 2.2 实例
- 2.3 解决方案
- 3.界面操作劫持
-
- 3.1 概念
- 3.2 实例
- 3.3 解决方案
- 4.漏洞挖掘
-
- 4.1 html内容中
-
- 4.1.1 大小写不敏感
- 4.1.2 嵌套绕过
- 4.1.3 svg注入(HTML5支持内联 SVG)
- 4.1.4 执行代码转换成unicode编码,再通过eval执行
- 4.2 HTML标签属性中
-
- 4.2.1 自行闭合双引号构造闭合标签
- 4.2.2 两个常见的输出例子
- 4.3 解决方案
- 5.WEB蠕虫
-
- 5.1 概念
- 5.2 页面操作劫持蠕虫的由来
- 5.3 技术分析
- 5.4 解决方案
- 6.控制台注入代码
-
- 6.1 概述
- 6.2 解决方案
- 7.钓鱼
-
- 7.1 概述
- 7.2 实例
- 7.3 解决方案
1.跨站脚本(XSS)
1.1 概念
- 全称:Cross Site Script(跨站脚本)
为了与层叠样式表css区分,将跨站脚本简写为XSS。 - 危害:
盗取用户信息、钓鱼、制造蠕虫等。 - 概念:
黑客通过“HTML注入”篡改了网页,插入了恶意脚本,从而在用户在浏览网页时,实现控制用户浏览器行为的一种攻击方式。
黑客可以利用xss盗取用户的cookie,有了用户的cookie,可以以用户的身份来正常访问站点。XSS属于客户端代码注入,通常注入代码是JavaScript。区别于命令注入,SQL注入属于服务端代码注入。简单的来说,就是在网页提供给用户输入的地方写入代码。
XSS分为三种类型:反射型,存储型,Dom型。
1.2 分类
1.2.1 反射型
一般来说这种类型的XSS,需要攻击者提前构造一个恶意链接,来诱使客户点击,比如这样的一段链接:
www.abc.com/?params=<script>alert(/xss/)</script>
1.2.2 存储型
这种类型的XSS,危害比前一种大得多。比如一个攻击者在论坛的楼层中包含了一段JavaScript代码,并且服务器没有正确进行过滤输出,那就会造成浏览这个页面的用户执行这段JavaScript代码。
1.2.3 DOM XSS
这种类型则是利用非法输入来闭合对应的html标签。比如,有这样的一个a标签:
<a href='$var'></a>
乍看问题不大,可是当$var
的内容变为’ οnclick=’alert(/xss/) //
,这段代码就会被执行。
1.3 实例
这里我们讲的是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>
界面是这样的:
我们首先输入123,看看能得到什么结果:
去看看源码:
我们输入的字符串被原封不动输出了,这样的话,如果我们将123替换成bird 也会被原封不动的输出,由于alert()
函数的功能是弹出对话框,那么也就是说我们输入上面的语句就会弹框,现在来看看。
假如我们输入类似下面的内容,页面会如下:
果不其然真的弹框了,这就说明这个web页面存在XSS漏洞。再去看看源码:
1.4 解决方案
对用户的输入进行转义,即可解决XSS。但是我们现在都是用框架进行开发,例如Vue,React,angular,而XSS常是基于DOM的,而框架很少去操作Dom,并且框架底层也对XSS做了一些防范。
2.跨站请求伪造(CSRF)
2.1 概念
- 全称:
Cross-site request forgery(跨站请求伪造) - 危害
个人隐私泄露以及财产安全。 - 概念
攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作(如发邮件,发消息,甚至财产操作如转账和购买商品)。由于浏览器曾经认证过,所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞:简单的身份验证只能保证请求发自某个用户的浏览器,却不能保证请求本身是用户自愿发出的。
2.2 实例
如下,点击登录进入一个网站,可以在文章下面发表一条评论并且记住自己的用户名。
当你点击这个链接,你会发现刚才的网站你的账户名又发表了一个新的留言,这个就是CSRF。
用户在网站登录后,这个网站服务端会在 Cookie 中会放一个凭证,这个凭证是后端用来验证用户身份的。在发评论的时候,提交评论的请求会带上这个凭证,后端通过判断这个凭证,来确认是哪个用户。
登录时,设置 Cookie:
提交评论时,携带 Cookie:
我们再来看看,发起攻击的页面里的内容。
<body style="display: none;">
<form target="myIframe" id="csrf" action="https://www.kkkk1000.com/csrf/data/post_comment.php" method="POST">
<input type="text" name="content" value="csrf攻击" />
</form>
<!-- iframe 用来防止页面跳转 -->
<iframe id="myIframe" name