XSS攻击与CSRF攻击

最新推荐文章于 2024-05-22 10:49:06 发布

charlene程程

最新推荐文章于 2024-05-22 10:49:06 发布

阅读量1.6k

点赞数 2

分类专栏： javascript 文章标签：安全问题

本文链接：https://blog.csdn.net/charlene0824/article/details/51135647

版权

javascript 专栏收录该内容

32 篇文章 0 订阅

订阅专栏

XSS攻击与CSRF攻击

XSS攻击

XSS（Cross SiteScript）跨站脚本攻击，是Web程序中常见的漏洞，XSS属于被动式且用于客户端的攻击方式，所以容易被忽略其危害性。其原理是攻击者向有XSS漏洞的网站中输入(传入)恶意的HTML代码，当其它用户浏览该网站时，这段HTML代码会自动执行，从而达到攻击的目的。如，盗取用户Cookie、破坏页面结构、重定向到其它网站等。

XSS攻击类似于SQL注入攻击，攻击之前，我们先找到一个存在XSS漏洞的网站，XSS漏洞分为两种，一种是DOM Based XSS漏洞，另一种是Stored XSS漏洞。理论上，所有可输入的地方没有对输入数据进行处理的话，都会存在XSS漏洞，漏洞的危害取决于攻击代码的威力，攻击代码也不局限于script。

（1）. DOM Based XSS

DOM Based XSS是一种基于网页DOM结构的攻击，该攻击特点是中招的人是少数人。

场景一
当我登录a.com后，我发现它的页面某些内容是根据url中的一个叫content参数直接显示的，猜测它测页面处理可能是这样，其它语言类似：

<html>
    <head>
       <title>XSS测试</title>
    </head>

    <body>

       页面内容：<%=request.getParameter("content")%>

    </body>

</html>

我知道了Tom也注册了该网站，并且知道了他的邮箱(或者其它能接收信息的联系方式)，我做一个超链接发给他，超链接地址为：http://www.a.com?content=，浏览器展示页面内容的过程中，就会执行我的脚本，页面输出xss字样，这是攻击了我自己，那我如何攻击别人并且获利呢？

（2）. Stored XSS
Stored XSS是存储式XSS漏洞，由于其攻击代码已经存储到服务器上或者数据库中，所以受害者是很多人。

场景二：

a.com可以发文章，我登录后在a.com中发布了一篇文章，文章中包含了恶意代码，，保存文章。这时Tom和Jack看到了我发布的文章，当在查看我的文章时就都中招了，他们的cookie信息都发送到了我的服务器上，攻击成功！这个过程中，受害者是多个人。
Stored XSS漏洞危害性更大，危害面更广。
（3）. XSS防御
XSS防御有如下方式。
* 完善的过滤体系
永远不相信用户的输入。需要对用户的输入进行处理，只允许输入合法的值，其它值一概过滤掉。
Html encode
假如某些情况下，我们不能对用户数据进行严格的过滤，那我们也需要对标签进行转换。

less-than character<	“&lt”;
greater-than character<	“&gt”;
ampersand character&	“&amp”;
double-quote character”	“&quot”;
space character()	“&nbsp”;

CSDF攻击

CSRF（Cross-site request forgery跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。

你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账……造成的问题包括：个人隐私泄露以及财产安全。

CSDF攻击原理

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

　　1.登录受信任网站A，并在本地生成Cookie。

　　2.在不登出A的情况下，访问危险网站B。

CSDN的防御

CSRF的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的CSRF防御也都在服务端进行。

　　（1）. 服务端进行CSRF防御

　　服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数。

　　(1).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="&amp;amp;lt;?=$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 {
 //...
 }
?>

这个方法个人觉得已经可以杜绝99%的CSRF攻击了，那还有1%呢….由于用户的Cookie很容易由于网站的XSS漏洞而被盗取，这就另外的1%。一般的攻击者看到有需要算Hash值，基本都会放弃了，某些除外，所以如果需要100%的杜绝，这个不是最好的方法。
　　(2).验证码

　　这个方案的思路是：每次的用户提交都需要用户在表单中填写一个图片上的随机字符串，这个方案可以完全解决CSRF，但个人觉得在易用性方面似乎不是太好，还有听闻是验证码图片的使用涉及了一个被称为MHTML的Bug，可能在某些版本的微软IE中受影响。

　　(3).One-Time Tokens(不同的表单包含一个不同的伪随机值)

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

　　以下我的实现:

　　1).先是令牌生成函数(gen_token())：

<?php
function gen_token() {
//这里我是贪方便，实际上单使用Rand()得出的随机数作为令牌，也是不安全的。
//这个可以参考我写的Findbugs笔记中的《Random object created and used only once》
 $token = md5(uniqid(rand(), true));
  return $token;
}

　　2).然后是Session令牌生成函数(gen_stoken())：

<?php
 function gen_stoken() {
　$pToken = "";
if($_SESSION[STOKEN_NAME]  == $pToken){
//没有值，赋新值
　$_SESSION[STOKEN_NAME] = gen_token();
　　　}   
else{
　　　　//继续使用旧的值
　　　}
 　　}
 ?>

　　3).WEB表单生成隐藏输入域的函数：　　

 <?php
 function gen_input() {
gen_stoken();
echo "<input type=\"hidden\" name=\"" . FTOKEN_NAME . "\"value=\"" . $_SESSION[STOKEN_NAME] . "\"> ";
 　　}
 ?>

　　4).WEB表单结构：

 <?php
      session_start();
      include(”functions.php”);
 ?>
 <form method=”POST” action=”transfer.php”>
      <input type=”text” name=”toBankId”>
      <input type=”text” name=”money”>
      <? gen_input(); ?>
      <input type=”submit” name=”submit” value=”Submit”>
 </FORM>

　　5).服务端核对令牌：

　　这个很简单，这里就不再啰嗦了。

　　上面这个其实不完全符合“并行会话的兼容”的规则，大家可以在此基础上修改。

参考文献：XSS攻击及防御
 浅谈CSRF攻击方式

charlene程程

关注

2
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
XSS攻击与CSRF攻击

XSS攻击与CSRF攻击XSS攻击XSS（Cross SiteScript）跨站脚本攻击，是Web程序中常见的漏洞，XSS属于被动式且用于客户端的攻击方式，所以容易被忽略其危害性。其原理是攻击者向有XSS漏洞的网站中输入(传入)恶意的HTML代码，当其它用户浏览该网站时，这段HTML代码会自动执行，从而达到攻击的目的。如，盗取用户Cookie、破坏页面结构、重定向到其它网站等。XSS攻击类似于S
复制链接

扫一扫