本文链接：https://blog.csdn.net/dhr201499/article/details/81097639

web安全测试

web安全测试之xss攻击

xss的全称是Cross Site Scripting（跨站脚本攻击），是一种注入式攻击。基本的做法是把恶意代码注入到目标网站。由于浏览器在打开目标网站的时候并不知道哪些脚本是恶意的，所以浏览器会无差别执行恶意脚本，从而导致用户信息和一些敏感信息被盗取和泄漏。

XSS攻击通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是JavaScript，但实际上也可以包括Java，VBScript，ActiveX，Flash或者甚至是普通的HTML。攻击成功后，攻击者可能得到更高的权限（如执行一些操作）、私密网页内容、会话和cookie等各种内容。

持久化xss（存储型XSS）

不需要用户单击特定URL就能执行跨站脚本，攻击者事先将恶意JavaScript代码上传或存储到漏洞服务器中，只要受害者浏览包含此恶意JavaScript代码的页面就会执行恶意代码。

持久型 XSS 一般出现在网站的留言、评论、博客日志等交互处，恶意脚本被存储到客户端或者服务器的数据库中，当其他用户浏览该网页时，站点即从数据库中读取恶意用户存入的非法数据，然后显示在页面中，即在受害者主机上的浏览器执行恶意代码。 *

非持久化xss（反射型XSS、参数型跨站脚本）

这种类型的跨站脚本是最常见，也是使用最广的一种，主要用于将恶意脚本附加到URL地址的参数中，例如：

http://www.test.com/search.php?key="><script>alert("XSS")</script>

一般是攻击者通过特定手法（比如利用电子邮件），诱使用户去访问一个包含恶意代码的URL，当受害者单击这些专门设计的链接的时候，恶意JavaScript代码会直接在受害者主机上的浏览器执行。它的特点是只在用户单击时触发，而且只执行一次，非持久化，所以称为反射型跨站式脚本，通常出现在网站的搜索栏、用户登入口等地方，常用来窃取客户端 Cookies 或进行钓鱼欺骗。

预防措施

过滤特殊字符。

XSS漏洞是由于Web应用程序对用户的输入过滤不足而产生的，所以避免XSS的方法之一主要是将用户所提供的内容进行过滤，许多语言都有提供对HTML的过滤：

- PHP的htmlentities()或是htmlspecialchars()。 
- Python的cgi.escape()。 
- ASP的Server.HTMLEncode()。 
- ASP.NET的Server.HtmlEncode()或功能更强的Microsoft Anti-Cross Site Scripting Library 
- Java的xssprotect (Open Source Library)。 
- Node.js的node-validator。

使用HTTP头指定类型。

很多时候可以使用HTTP头指定内容的类型，使得输出的内容避免被作为HTML解析。如在PHP语言中使用以下代码：

<?phpheader('Content-Type: text/javascript; charset=utf-8');?>

即可强行指定输出内容为文本/JavaScript脚本（顺便指定了内容编码），而非可以引发攻击的HTML。

用户方设置。

包括Internet Explorer、Mozilla Firefox在内的大多数浏览器皆有关闭JavaScript的选项，但关闭功能并非是最好的方法，因为许多网站都需要使用JavaScript语言才能正常运作。通常来说，一个经常有安全更新推出的浏览器，在使用上会比很久都没有更新的浏览器更为安全。

web安全之csrf攻击

csrf攻击的全称是Cross-Site Request Forgery（跨站请求伪造）攻击，简单来说是利用当前用户的登录态冒充该用户去做一些对受害者不利的事情。

从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：

登录受信任网站A，并在本地生成Cookie。
在不登出A的情况下，访问危险网站B。

简单的例子：

假设Alice想通过ban.com网站给bob转100块钱，当然了，bank.com是有安全漏洞的，不能防止csrf攻击。Maria，一个攻击者，想通过一些不正当手段让Alice转账给她，下面是她的一些做法:

构造攻击的链接或脚本
通过社交网站诱骗Alice去点击伪造链接或执行脚本

如果bank.com银行应用是通过GET加传参的方式进行转账，如下所示：

GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

那么Maria现在决定让Alice成为受害者，她开始伪造url，让Alice从账户中转10000块钱到自己账户。她通过替换链接中参数的方式来达到这一目的。

http://bank.com/transfer.do?acct=MARIA&amount=100000

现在就到了诱导受害者去点击或执行上面这个链接的时候了，一般来说有下面一些方法:

自动发送包含html内容的垃圾邮件
在Alice浏览银行站点时经常会访问的页面上构造恶意的链接或放置恶意脚本，比如伪装成一个普通链接，鼓励被害者去点击。

<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">看我的照片!</a>

又或者构造一个0x0大小的图片

<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="0" height="0" border="0">

把上面这个图片放到emial中，Alice收到email之后，该链接会自动被访问。

如果Alice在点击上面的链接或打开email时正好登录了bank.com，那么上面的请求也会获得bank.com的登录态，从而发生转账行为。

CSRF的防御

服务端进行CSRF防御

Cookie Hashing(所有表单都包含同一个伪随机值)：

这可能是最简单的解决方案了，因为攻击者不能获得第三方的Cookie(理论上)，所以表单中的数据也就构造失败了.

　<?php
　　　　//构造加密的Cookie信息
　　　　$value = “DefenseSCRF”;
　　　　setcookie(”cookie”, $value, time()+3600);
　　?>

在表单里增加Hash值，以认证这确实是用户发送的请求。

　<?php
　　　　$hash = md5($_COOKIE['cookie']);
　　?>
　　<form method=”POST” action=”transfer.php”>
　　　　<input type=”text” name=”toBankId”>
　　　　<input type=”text” name=”money”>
　　　　<input type=”hidden” name=”hash” value=”<?=$hash;?>”>
　　　　<input type=”submit” name=”submit” value=”Submit”>
　　</form>

然后在服务器端进行Hash值验证

 <?php
　　      if(isset($_POST['check'])) {
     　　      $hash = md5($_COOKIE['cookie']);
          　　 if($_POST['check'] == $hash) {
               　　 doJob();
　　           } else {
　　　　　　　　//...
          　　 }
　　      } else {
　　　　　　//...
　　      }
      ?>

验证码。
One-Time Tokens(不同的表单包含一个不同的伪随机值)

在实现One-Time Tokens时，需要注意一点：就是“并行会话的兼容”。如果用户在一个站点上同时打开了两个不同的表单，CSRF保护措施不应该影响到他对任何表单的提交。考虑一下如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况：用户只能成功地提交他最后打开的表单，因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保CSRF保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。

参考：测试教程网

参考：浅谈CSRF攻击方式

参考：浅谈Web安全-XSS攻击