本文目录一览：
- 1、xss攻击的实例
- 2、45. 从零开始学springboot撸一个Xss过滤器-注解实现
- 3、前端安全机制问题之一（XSS）
- 4、OAuth回调参数漏洞案例解析
- 5、CRLF注入攻击
- 6、谁能说一下脚本病毒的原理、攻击流程与防护、、最好详细点呀、网站也好、谢啦、、
xss攻击的实例
XSS又叫CSS (Cross Site Script) ，跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意攻击用户的特殊目的。XSS属于被动式的攻击，因为其
45. 从零开始学springboot撸一个Xss过滤器-注解实现
上章通过Filter实现了Xss全局过滤器
可能小伙伴还有点不满, 全局意味着“一刀切”,
虽然我们也有白名单黑名单设置, 但是, 白名单黑名单针对的是整个方法或整个实体类
举个例子, 我定义了个实体
可能业务上有限制(比如name限制了只有5个字符长),
那么name其实不可能存在Xss注入风险了,
程序只需要对info和des属性做转义即可
如果采用Filter, 意味着People的所有属性都会检测转义, 好像没啥必要!
那么, 可以针对性的指定字段进行Xss的过滤转义么?
为了应对这样的需求, 咸鱼君采用Aop注解来实现这么个Xss过滤器.
PS: 和Filter一样, 我们统一对入参Xss过滤, 确保参数的处理方式统一! 所以, 程序中获取的参数值都是转义后的数据!!
废话不多说, 往下看!
加入必要的pom依赖
针对方法, 参数, 属性分别定义三个注解
XssMethod
XssParam
XssField
针对注解实现切面Aspect
XssAspect
注释写的很详细, 就不多废话了!
接下来我们写个案例来测试测试
首先在启动类上启用切面
定义一个实体People, 并对info,des属性加上注解进行xss过滤
最后编写controller
json方式
键值对方式
前端安全机制问题之一（XSS）
作为安全方面的小白，笔记当然要从基础开始，简单的来
先说说XSS即跨站脚本攻击
//使用“\”对特殊字符进行转义，除数字字母之外，小于127使用16进制“\xHH”的方式进行编码，大于用unicode（非常严格模式）。
HtmlEncode
将字符转换成HTMLEntites，以对抗XSS,这个方法要意义啊去匹配，感觉有点麻烦，但是好在容易理解
这里给一个测试案例看看
不是我想吐槽，我想说要是真心都这样写，先不说写的人如何，对接手的人来说就是噩梦
接着来提供另外的方法：在表单提交或者url参数传递前，对需要的参数进行过滤
这个就留给大家来填充吧，我要搬砖去了
OAuth回调参数漏洞案例解析
OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAUTH的授权不会使第三方触及到用户的帐号信息(如用户名与密码)，即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此OAUTH是安全的。oAuth是Open Authorization的简写。
OAuth 2.0中有6种常用的授权类型:
本文只介绍其中的Authorization Code(授权码模式),这也是目前国内大部分厂商使用的模式
例如新浪微博这里就提供了多种第三方登陆,下面笔者以”用QQ号登陆新浪微博”这个实例来讲解OAuth认证的原理
我们把”微博”称作客户端,”QQ”称作服务端
点击QQ登陆的图标,用户将被导向服务端的认证服务器
用户在此选择是否给予客户端(微博)授权,如果授权,则客户端将会获得用户在服务端(QQ)的昵称,头像和性别资料
先来看下这个URL
这其中有重要意义的参数有以下几个:
客户端标识,这个参数是和客户端一一对应的,这样服务端才知道认证请求来自哪个客户端.例如”101019034”代表的就是新浪微博这个客户端
授权类型,上文已经说了OAuth有多种授权类型.此处”code”代表使用的是Authorization Code(授权码模式)
申请的权限范围
重定向URI,用户给予授权后,将会携带授权码跳转到此地址
这个参数是用来防御CSRF的,你可以将其理解为我们常用的”token”.这里它的使用和”token”也是一样的
每次授权请求,客户端都会生成一个state,并将其保存到cookie或session中.授权成功后,服务端原样返回state,客户端将其与cookie或session中的值进行比对
回到授权过程,如果用户点击了QQ头像确认授权
认证服务器确认用户身份后,会生成一个授权码(code),然后将用户导向之前redirect_uri指定的地址,并附带上授权码(code)和state
state的作用已经说过是防御CSRF的,最终要的就是这个code了
客户端收到授权码(code)后,将其发送到服务端比对(这一步在客户端后台服务器完成,对用户不可见)
如果比对结果一致,那么游戏结束
在这个请求中,比对结束后,生成了一个alt,并跳转到了login.sina.com.cn域
验证了alt后,就在.sina.com.cn域种上cookie了.
从这个登陆案例来看,只要攻击者拿到了code参数,那么就能劫持用户的微博账号.
有经验的攻击者一定发现了,既然code参数会发送到redirect_uri参数指定的地址,那么只要让redirect_uri跳转到我们指定的地址,那么就能窃取code.
虽然redirect_uri不能任意指定,但是微博的业务设定为了可以跳转到任意weibo.com的子域下.
如果我们能在某个子域下的某个页面引入外部资源(img,vedio的href属性;script标签的src属性),再让redirect_uri携带code跳转到这个页面,那么我们就能从referer头里窃取到code.
你可能首先会想到XSS,但是现在XSS不是那么好找了,而且用在这里有点大材小用.其实只要我们能引入一个外部图片就行了.
这种功能很常见,很多地方都允许插入在线图片.
我在xxx.weibo.com域下的一个帖子里插入了一个在线图片,图片地址填ceye平台地址.
然后修改redirect_uri为该帖子的地址.
然后把这个链接发给受害者,一旦他点击头像确认登陆,携带code的请求就会被导向到攻击者引入了外部图片的页面.
页面加载了img标签后,code就会通过referer头泄露出去.
上文已经说过,只要攻击者拿到code,那么发送给passport.weibo.com进行认证,就能劫持用户的微博账号了.
看了案例1,你可能会觉得应该由xxx.weibo.com背锅,如果严格限制redirect_uri跳转到指定域,就不会由问题了.
这是在一次众测遇到的一个案例,貌似还没修复,就不说名字了.
该厂允许绑定淘宝账号进行第三方登陆,
并且严格限制了只能跳转到a.xxx.com域下,所以上面那种随便找个子域插入图片的套路看来是不行了.
但不幸的是,我正巧的a.xxx.com域下找到一个XSS,
所以,我们能更方便的写入img或者scritp标签了,后面窃取code的方法和上面一样,就不多说了.
通过上面2个案例,我们可以得出这样的结论:
不仅要严格限制redirect_uri跳转的域,而且要保证其跳转到一个安全的域.
但是,人在广东已经….啊不对,人在家中坐,锅从天上来.
360作为服务端为其它厂商提供了OAuth认证的功能,开发者可以在360应用开发平台进行申请.
人家不仅提供了详细的开发文档,还给开发者弄了个调试工具.
理论上呢,redirect_uri是开发者自己填的,为了安全,只能是某个安全的域名.
但是,360为了便于开发者进行登陆调试,把”openapi.360.cn”这个域名设置成了所有应用的合法回调地址.
那么openapi.360.cn这个域的安全性直接影响到所有客户端.
不幸的是,我又在openapi.360.cn下找到一个XSS,
所以,又能快乐的窃取到code了,并且影响了所有使用360账号登陆的应用.
关于OAuth认证,还有其它的授权类型以及各种漏洞有待探索.
对于本文提及的授权码模式,其中的redirect_uri参数应该有以下递进式的限制:
原文：
回调参数漏洞案例解析/
CRLF注入攻击
一、概念
回车换行（CRLF）注入攻击，又称HTTP头部返回拆分攻击，是一种当用户将CRLF字符插入到应用中而触发漏洞的攻击技巧。原理是服务器未过滤攻击者输入的数据，而直接放到头部，导致攻击者通过注入\n\r（%0d%0a）能够控制HTTP返回头部。CRLF字符（%0d%0a）在许多互联网协议中表示行的结束，包括HTML，该字符解码后即为\ r\ n。这些字符可以被用来表示换行符，并且当该字符与HTTP协议请求和响应的头部一起联用时就有可能会出现各种各样的漏洞，从而造成XSS注入攻击、Web缓存中毒、会话固定漏洞、302跳转攻击等攻击。。
二、测试案例
一般网站会在HTTP头中用Location: 这种方式来进行302跳转，所以我们能控制的内容就是Location:后面的XXX某个网址。
比如一个网站接受url参数放在Location后面作为一个跳转。
1、会话固定漏洞
如果我们输入的是，注入了一个换行，此时的返回包就会变成这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location:
Set-cookie: JSPSESSID=wooyun
这个时候这样我们就给访问者设置了一个SESSION，造成一个“会话固定漏洞”。
2、反射型XSS
如果我们输入的是：;img src=1 onerror=alert(/xss/)
我们的返回包就会变成这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location:
img src=1 onerror=alert(/xss/)
三、解决方法
1、不要把用户的输入直接输出。
2、过滤用户输入的\r\n。
3、可以使用urlencode，对输出的文件名做url编码。
谁能说一下脚本病毒的原理、攻击流程与防护、、最好详细点呀、网站也好、谢啦、、
通过对xss跨站脚本攻击漏洞的历史、攻击特点、攻击原理描述及案例代码实战举例详细解析XSS漏洞攻击技术，并提出防御XSS跨站漏洞的思路方法。及WEB开发者开发网站过程中防范编码中产生xss跨站脚本攻击漏洞需要注意的事项。
XSS漏洞概述：
XSS(Cross Site Script)跨站点脚本攻击是一种注射的问题，在这种恶意脚本注入否则良性和信任的网站类型。跨站点脚本（XSS）攻击，攻击者使用时，会出现一个网络应用程序发送恶意代码，一般是在浏览器端脚本的形式，向不同的最终用户。这些缺陷，使攻击成功是相当普遍，发生在任何地方从一个Web应用程序使用在输出它没有验证或编码了用户输入。攻击者可以使用XSS的恶意脚本发送到一个毫无戒心的用户。最终用户的浏览有没有办法知道该脚本不应该信任，将执行该脚本。因为它认为该脚本来从一个受信任的源，恶意脚本可以访问任何Cookie，会话令牌，或其他敏感信息的浏览器保留，并与该网站使用。 甚至可以重写这些脚本的HTML网页的内容。
XSS漏洞历史：
XSS(Cross-site scripting)漏洞最早可以追溯到1996年，那时电子商务才刚刚起步，估计那时候国内很少人会想象到今天出现的几个国内电子商务巨头淘宝、当当、亚马逊（卓越）。XSS的出现“得益”于JavaScript的出现，JavaScript的出现给网页的设计带来了无限惊喜，包括今天风行的AJAX(Asynschronous JavaScript and XML)。同时，这些元素又无限的扩充了今天的网络安全领域。
XSS 漏洞攻击特点：
（1）XSS跨站漏洞种类多样人：
XSS攻击语句可插入到、URL地址参数后面、输入框内、img标签及DIV标签等HTML函数的属人里、Flash的getURL()动作等地方都会触发XSS漏洞。
（2）XSS跨站漏洞代码多样人：
为了躲避转义HTML特殊字符函数及过滤函数的过滤，XSS跨站的代码使用“/”来代替安字符“””、使用Tab键代替空格、部分语句转找成16进制、添加特殊字符、改变大小写及使用空格等来绕过过滤函数。
如果在您的新闻系统发现安全漏洞，如果该漏洞是一个SQL 注入漏洞，那么该漏洞就会得到您的网站管理员密码、可以在主机系统上执行shell命令、对数据库添加、删除数据。如果在您的新闻或邮件系统中发现安全漏洞，如果该漏洞是一个XSS跨站漏洞，那么可以构造一些特殊代码，只要你访问的页面包含了构造的特殊代码，您的主机可能就会执行木马程序、执行^***Cookies代码、突然转到一个银行及其它金融类的网站、泄露您的网银及其它账号与密码等。
XSS攻击原理：
XSS 属于被动式的攻击。攻击者先构造一个跨站页面，利用script、IMG、IFRAME等各种方式使得用户浏览这个页面时，触发对被攻击站点的http 请求。此时，如果被攻击者如果已经在被攻击站点登录，就会持有该站点cookie。这样该站点会认为被攻击者发起了一个http 请求。而实际上这个请求是在被攻击者不知情的情况下发起的，由此攻击者在一定程度上达到了冒充被攻击者的目的。精心的构造这个攻击请求，可以达到冒充发文，夺取权限等等多个攻击目的。在常见的攻击实例中，这个请求是通过script 来发起的，因此被称为Cross Site Script。攻击Yahoo Mail 的Yamanner 蠕虫是一个著名的XSS 攻击实例。Yahoo Mail 系统有一个漏洞，当用户在web 上察看信件时，有可能执行到信件内的javascript 代码。病毒可以利用这个漏洞使被攻击用户运行病毒的script。同时Yahoo Mail 系统使用了Ajax技术，这样病毒的script 可以很容易的向Yahoo Mail 系统发起ajax 请求，从而得到用户的地址簿，并发送病毒给他人。
XSS 攻击主要分为两类：一类是来自内部的攻击，主要指的是利用WEB 程序自身的漏洞，提交特殊的字符串，从而使得跨站页面直接存在于被攻击站点上，这个字符串被称为跨站语句。这一类攻击所利用的漏洞非常类似于SQL Injection 漏洞，都是WEB程序没有对用户输入作充分的检查和过滤。上文的Yamanner 就是一例。
另一类则是来来自外部的攻击，主要指的自己构造XSS 跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页。如当我们要渗透一个站点，我们自己构造一个跨站网页放在自己的服务器上，然后通过结合其它技术，如社会工程学等，欺骗目标服务器的管理员打开。这一类攻击的威胁相对较低，至少ajax 要发起跨站调用是非常困难的。