正则表达式简介

正则表达式(Regular Expression)是一种文本模式,包括普通字符(例如,a~z之间的字母)和特殊字符(称为“元字符”)
正则表达式使用单个字符串来描述、匹配一系列匹配某个语法规则的字符串。

模块总览

  • 1.Target(目标):显示目标目录结构。
  • 2.Proxy(代理):拦截HTTP(S)的代理服务器,作为一个在浏览器和目标应用程序之间的中间人,可控制拦截、查看、修改在两个方向上的原始数据流。
  • 3.Spider(爬虫):应用智能感应的网络爬虫,能完整的枚举应用程序的内容和功能。
  • 4.Scanner(扫描):执行后(running)它能自动地发现web 应用程序的安全漏洞。
  • 5.Intruder(入侵):定制的、高度可配的工具,对web应用程序进行自动化攻击,
  • 6.Repeater(中继器):通过手动操作来触发单独的HTTP请求,并分析应用程序响应。
  • 7.Sequencer(会话):用来分析那些不可预知的应用程序会话令牌和重要数据项的随机性。
  • 8.Decoder(解码器)——进行手动执行或对应用程序数据者智能解码编码的工具。
  • 9.Comparer(对比)——通常是通过一些相关的请求和响应得到两项数据的一个可视化的“差异”对比。
  • 10.Extender(扩展):可以让你加载Burp Suite的扩展,也就是自己可以制作的扩展插件

总结:2018.09.19
做一个充满兴趣有决心的安全小白,多多学习,多多练习,要熟练而不是熟悉,充实自己,做你所想。加油吧少年!!!

注入攻击漏洞

#简介
  注入攻击是web领域中最常见的一种攻击。注入攻击的本质就是把用户输入的数据当作代码执行,需满足:

  • 第一用户能够控制输入
  • 第二原本程序要执行的代码拼接了用户输入数据。

即能实现注入攻击,在注入攻击中最常见的就是SQL注入。

注入攻击是WEB安全领域中一种最为常见的攻击方式。在“跨站脚本攻击”一章中曾经提到过,XSS本质上也是一种针对HTML的注入攻击。在“我的安全世界观” 一章中,提出一个安全设计原则—-“数据与代码分离”的原则,它可以说是专门为了解决注入攻击而生的。 ———-《白帽子讲WEB安全》

sql注入

  SQL注入的本质就是通过构造特殊的用户输入,绕过代码限制,使用户输入的数据带入数据库执行,获得更多的信息或更大的权限。解决办法“数据与代码分离”,数据库只处理数据。

sql注入基本原理

1.判断是否含有注入点:

1
2
3
4
5
命令:


and 1=1
and 1=2

2.判断注入类型:(一般考虑数字型/字符型)
  尝试字符型输入:1'or'1'='2(如果是字符型显示会输入id=1的结果)
  尝试字符型:输入数字计算(例:2-1 如果是数字型注入,这里显现的结果应该等同于ID=1)
3.判断数据库类型:

  • 有时在输入错误数据(比如:输入‘引起执行语句的语法错误)时,根据错误回显能够看出数据库类型。
  • 但很多时候,web关闭了错误回显,这时便用到了“盲注”技巧:所谓盲注:就是攻击者找到一个方法来验证sql语句是否得到执行,最常见的盲注验证方法是,构造简单的条件语句,根据返回页面的信息是否发生变化,来判断SQL语句是否被执行。

  首先判断and语句是否能够执行,在通过简单的条件语句判断,对比页面返回结果差异
4.根据获得信息,构造sql语句撞库(此过程也可以由软件完成,比如sqlmap)

防御SQL注入

防御本质

从防御的角度来看,要做的事情有两件:
  (1)找到所有的SQL注入漏洞;
  (2)修补这些漏洞
解决好这两个问题,就能有效的防御SQL注入攻击。

防御SQL注入的方法

 1.使用预编译语句,绑定变量:使用预编译的SQL语句,SQL语句的语义不会发生改变。变量用?表示,攻击者无法改变SQL结构。
 2.使用安全的存储过程对抗SQL注入,存储过程先将SQL语句定义在数据库中。但需要注意存储过程中也可能会存在诸如问题,因此应该尽量避免在存储过程内使用动态的SQL语句。
 3.检查输入数据的数据类型,在很大程度上可以对抗SQL注入,(过滤字符)
 4.使用安全函数(最小授权原则)

其他注入攻击

XML注入

  XML是一种常用的标记语言,通过标签对数据进行结构化表示。XML与HTML都是SGML(Standard generalized markup language,标准通用标记语言)
XML满足注入攻击的两大条件:

  • 用户能控制数据的输入。
  • 程序拼凑了数据。

修补方案与HTML类似,对用户输入数据中包含的“语言本身的保留字符”进行转义。

代码注入

  代码注入与命令注入往往都是由一些不安全的函数或方法引起的,其中的典型代表就是eval()。

CRLF注入

  CRLF实际上是两个字符:CR是Carriage Return(ASCLL 13,\R),LF是Line Feed(ASCLL 10,\n).\r\n这两个字符是用于表示换行的,其十六进制分别为0x0d、0x0a。
  CRLF常被用作不同语义之间的分隔符。因此通过“注入CRLF字符”,就有可能改变原有的语义。
  对抗CRLF的方法只需要处理好\r、\n这两个保留字符即可,尤其是那些使用“换行符”作为分隔符的应用。

小结

  注入攻击是应用违背了“数据与代码分离原则”导致的结果。它有两个条件:

  • 用户能控制输入;
  • 代码拼凑了用户输入的数据,把代码当作数据执行了。

  在对抗注入攻击时,只需要牢记“数据与代码分离原则”,在“拼凑”发生的地方进行安全检查,就能避免此类问题。

  版权所有,侵权必究。

应用层拒绝服务攻击

DDOS简介

  DDOS(Distributed Denial Of Service)又称为分布式拒绝服务,导致服务不可用。分布式拒绝服务攻击,将正常请求放大了若干倍,通过若干个网络节点同时发起攻击,已达到规模效应。
  常见的DDOS攻击有SYN flood、UDP flood、ICMP flood等。以SYN flood攻击为例,SYN flood在攻击时,首先伪造大量的源IP地址,分别向服务器端发送大量的SYN包,此时服务器端会返回SYN/ACK包,因为源地址是伪造的,所以伪造的IP并不会应答,服务器端没有收到伪造IP的回应,会重复3~5次并且等待一个SYN Time(一般为30秒~2分钟),如果超时则丢弃这个连接。攻击者大量发送这种伪造源地址的SYN请求,服务器端将消耗非常多的资源(CPU、内存)来处理这种半连接,同时还要不断的对这些IP进行SYN+ACK重试。最后的结果是服务器无暇理睬正常的连接请求,导致拒绝服务。
  对抗SYN flood的主要措施有SYNCookie/SYNProxy、safereset等方法。SYN Cookie的主要思想是为每一个IP地址分配一个“cookie”,并统计每个IP地址的访问频率,如果在短时间内收到大量来自同一IP地址的数据包,则认为受到攻击,之后来自这个IP地址的包将被丢弃
  在很多对抗DDOS的产品中,一般会综合使用各种方法,结合一些DDOS攻击的特征,对流量就行清洗。对抗DDOS的网络设备可以串联或者并联在网络出口处。

应用层DDOS

  应用层DDOS,不同于网络层DDOS,由于发生在应用层,因此TCP三次握手已经完成,连接已经建立,所以发起攻击的IP地址也都是真实的,但应用层DDOS有时甚至比网络层DDOS攻击更可怕,因为几乎所有的Anti-DDOS设备,只在对抗网络层DDOS时效果较好,而对应用层DDOS攻击却缺乏有效的对抗手段。

CC攻击

  CC(Challenge Collapasar)攻击,其原理是对一些消耗资源较大的应用页面不断发起正常的请求,以达到消耗服务端资源的目的。
  应用层DDOS攻击是针对服务器性能的一种攻击,那么许多优化服务器性能的方法,都或多或少地能缓解此种攻击。比如将使用频率高的数据放在memcache中,相对于查询数据库所消耗的资源来说,查询memcache所消耗的资源可以忽略不计。但很多性能优化的方案并非是为了对抗应用层DDOS攻击设计的,因此攻击者想要找到一个资源消耗大的页面并不困难。比如当memcache查询没有命中时,服务器必然会查询数据库,从而增大服务器资源的消耗,攻击者只需要找到这样的页面即可。同时攻击者除了触发“读”数据操作外,还可以触发“写”数据操作,“写”数据的行为一般会导致服务器操作数据库。

限制请求频率

  最常见的针对应用层DDOS攻击的防御措施,是在应用中针对每个“客户端”做一个请求频率限制。思路很简单,通过IP地址与cookie定位一个客户端,如果客户端的请求在一定时间内过于频繁,则对之后来自该客户端的所有请求都重定向到一个出错的页面,是一个“基层”的安全模型。
  然而这种防御方法并不是完美的,这个方案中有两个因素用以定位客户端:IP地址和cookie。但用户IP地址可能会发生变化,而cookie又可能会被清空,如果IP地址和cookie同时都发生变化,那么就无法同时定位到一个客户端了。
  可以从以下几个方面解决DDOS攻击:
1.应用代码要做好性能优化。合理地使用memcache就是一个很好的优化方案。将数据库的压力尽可能的转移到内存中。此外还需要及时的释放资源,比如及时关闭数据库链接,减少空连接等消耗。
2.在网络架构中做好优化。善于利用负载均衡分流,避免用户流量集中在单台服务器上,同时可以充分利用好CDN和镜像站点的分流作用,缓解主站的压力。
3.最重要的一点,实现一些对抗手段,比如限制每个IP地址的请求频率。

验证码

  验证码是互联网常用技术之一,它的英文简称是CAPTCHA(completely automated public Turing test to tell computers and humans apart 全自动区分计算机和人类的图灵测试)在很多时候,如果忽略用户体验考虑,那么引入验证码能够有效地阻止自动化的重放行为。
  有验证码就会有验证码破解技术,除了直接利用图像相关算法识别验证码外,还可以利用web实现上可能存在的漏洞破解验证码。因为验证码的验证过程,是比对用户提交的明文和服务器端session里保存的验证码明文是否一致。所以有验证码系统出现过这样的漏洞:因为验证码消耗掉后sessionID未更新,导致使用原有的SessionID可以一直重复提交同一个验证码。
  还有一种验证码实现方式,是提前将所有的验证码图片生成好,以哈希过的字符串作为验证码图片的文件名。在使用验证码时,则直接从图片服务器返回已经生成好的验证码,这种设计原本的想法是为了提高性能。但这种一一对应的验证码文件名会存在一个缺陷:攻击者可以事先采用枚举的方式,遍历所有的验证码图片,并建立验证码到明文之间的一一对应关系,从而形成一张“彩虹表”,这也会导致验证码形同虚设。修补的方式是验证码的文件名需要随机化,满足“不可预测性原则”。

防御应用层DDOS

  服务器应用可以通过判断HTTP头中的user-agent字段来识别客户端。但是HTTP头中的user-agent是可以被客户端篡改的,所以是不可信的。一种比较可靠的方法是让客户端解析一段JavaScript,并给出正确的运行结果。因为大部分的自动化脚本都是直接构造HTTP包完成的,并非在一个浏览器环境中发起的请求。因此一段需要计算的JavaScript,可以判断出客户端到底是不是浏览器。类似的,发送一个flash让客户端解析,也可以起到相同的作用。但是需要注意的是,这种方法并不是万能的,有的自动化脚本是内嵌在浏览器中的“内挂”,就无法检测出来了。

资源耗尽攻击

  拒绝服务攻击的本质实际上就是一种资源耗尽攻击,

Slowloris攻击

  Slowloris攻击,其原理是以极低的速往服务器发送HTTP请求。由于web server对于并发的连接数都有一定的上限,因此若是恶意地占用住这些连接不施放,那么web server的所有连接都将被恶意连接占用,从而无法接受新的请求,导致拒绝服务。(\r\n)

HTTP POST DOS

  其原理是在发送HTTP POST包时,制定一个非常大的content-length值,然后以很低的速度发包(比如:10~100S发一个字节),保持住这个连接不断开,这样当客户端连接数多了以后,占用住了web server的所有可用连接,从而导致DOS。

Server Limit DOS

  WEB Server对HTTP包头都有长度限制,如果客户端发送的HTTP包头超过这个大小,服务器就会返回一个4xx错误,假如攻击者通过XSS攻击,恶意的向客户端写入一个超长的cookie,cookie也是放在HTTP包头里发送的,而web server默认会认为这是一个超长的非正常请求,从而导致“客户端”的拒绝服务。
此类拒绝服务攻击的本质,实际上是对有限资源的无限滥用

ReDOS

  当正则表达式写的不好时,就有可能被恶意输入利用,消耗大量的资源,从而造成DOS,这种攻击被称为ReDOS。
  与前面提到的资源耗尽攻击略有不同的是,ReDOS是一种代码实现上的缺陷,正则表达式是基于NFA(nondeterministic finite automaton)的,他是一个状态机制,每个状态和输入符号都可能有许多不同的“下一个状态”。正则解析引擎将遍历所有的解析可能直到最后,由于每个状态都有若干个“下一个状态”,因此决策算法将逐个尝试每个“下一个状态”,直到找到一个匹配的。这极大地增加了正则引擎解析数据时的消耗当用户恶意构造输入时,这些有缺陷的正则表达式就会消耗大量的系统资源,从而导致整台服务器的性能下降,与拒绝服务的后果是一样的。

小结

  应用层拒绝服务攻击是传统的网络层拒绝服务攻击的一种延伸,其本质也是对有限资源的无限滥用造成的。因此解决这个问题的核心思路就是限制每个不可信的资源使用者的配额。

文件上传漏洞

简介

  文件上传漏洞是指用户上传了一个可执行的脚本文件,并通过此脚本文件获得了执行服务器端命令的能力。
  文件上传后导致的常见安全问题:
1.上传文件是web脚本语言,服务器的web容器解释并执行了用户上传的脚本,导致代码执行。
2.上传文件是Flash的策略文件crossdomain.xml,黑客用以控制flash在该域下的行为(其他通过类似方法控制策略文件的情况类似)
3.上传文件是病毒木马文件,黑客用以诱骗用户或者管理员下载执行。
4.上传文件是钓鱼图片或包含了脚本的图片,在某些版本的浏览器中会被作为脚本执行,被用于钓鱼和欺骗。
5.还有一些不是很常见的利用方法,比如将上传文件作为一个入口,溢出服务器的后台处理程序,如图片解析模块;或者上传一个合法的文件,其内容包含了PHP脚本,在通过“本地文件包含漏洞(local file include)”执行此脚本,等。

  在大多数情况下文件上传漏洞都是指“上传web脚本能够被服务器解析”的问题。也就是通常所说的webshell问题,要完成攻击,需要如下条件:
1.上传文件能够被web容器解释执行,所以文件上传后所在的目录要是web容器所覆盖到的路径。
2.用户能够从web上访问这个文件,如果文件上传了,但用户无法通过web访问,或者无法使用web容器解释这个脚本,那么也不能称之为漏洞。
3.用户上传的文件若是被安全检查、格式化、图片压缩等功能改变了内容,则也可能导致攻击不成功。

绕过文件上传检查功能

  在针对文件上传的检查中,很多应用都是通过判断文件名后缀的方法来验证文件的安全性的。但是在某些时候,如果攻击者手动修改了上传过程的post包,在文件名后添加一个%00字节,则可以截断某些函数对文件名的判断。因为在许多语言的函数中,比如在C、PHP等常用字符串处理函数中,0x00被认为是终止符。受此影响的环境有web应用和一些服务器。比如应用原本只允许上传JPG图片,那么可以构建文件名(需要修改POST包)为xxx.php[\0].jpg,其中[\0]为十六进制的0x00字符,JPG绕过了应用的上传文件类型判断但对于服务器端来说,此文件因为0字节截断的关系,最后会变成xxx.php。
  0x00字符截断问题,逻辑字符串处理,需要引起重视

  除了常见的检查文件名后缀的方法外,有的应用还会判断上传文件的文件头来验证文件的类型。在某些特定的环境下,伪造文件头的技巧可以收到奇效。

功能&&漏洞

  在文件上传漏洞的利用过程中,一些和web server本身特性相关的功能,如果加以利用,就会变成威力巨大的武器。

apache文件解析问题

  在apache1.x、2.x中Apache对于文件名的解析是从后往前解析的,直到遇见一个Apache认识的文件类型为止。

IIS文件解析问题

  PUT是在webdav中定义的一个方法。WebDav大大扩展了HTTP协议中GET、POST、HEAD等功能,它所包含的PUT方法,允许用户上传文件到指定路径下。在许多Web Server中默认禁止此方法。,或者对能够上传的文件类型做出了严格限制。但在IIS中,如果目录支持写权限,同时开启了WebDav,则会支持PUT方法,再结合MOVE方法,就能够将原本只允许上传文件改写为脚本文件,从而执行webshell。MOVE能否执行成功取决于IIS服务器是否勾选了“脚本资源访问”复选框
  一般要实施此攻击过程,攻击者应先通过options方法探测服务器支持的HTTP方法类型,如果支持PUT,则使用PUT上传一个指定的文本文件,最后再通过MOVE改写为脚本文件。

PHP CGI路径解析问题

  在fastcgi方式下,PHP获取环境变量的的方式,在映射url时,两个环境变量:PATH_INFO(记录路径信息),SCRIPT_FILENAME(检查文件是否存在(递归确认文件合法性))

利用上传文件钓鱼

  钓鱼者将包含了HTML的文件(比如一张图片)上传到目标网站,然后通过传播这个文件的url来进行钓鱼,则url中不会出现钓鱼网址,更具欺骗性。(前提是浏览器能够解析文件,并执行)

设计安全的文件上传功能

1.文件上传的目录设置为不可执行
2.判断文件类型
3.使用随机数改写文件名和文件路径
4.单独设置文件服务器的域名

小结

  文件上传问题看是简单,但要实现一个安全的上传功能,殊为不易。不断地发现问题,结合业务需求,才能设计出最合理、最安全的上传功能。

认证与会话管理

简介

  认证的目的是为了认出用户是谁,而授权的目的是为了决定用户能够做什么。
  认证实际上就是一个验证凭证的过程。

  如果只有一个凭证被用于认证,则称为”单因素认证”
  如果有两个或多个凭证被用于认证,则称为“双因素(two factors)认证”或”多因素认证”。

Session Fixation攻击

  没有换锁而导致的安全问题,就是Session Fixation问题,在用户登录网站的过程中,如果登陆前后用户的Session ID没有发生变化,则会存在Session Fixation问题。
  解决Session Fixation问题的正确做法是,在登录完成后,重写SessionID。如果使用sid则需要重置sid的值;如果使用cookie,则需要增加或修改用于认证的cookie值。

Session保持攻击

  一般来说Session是有生命周期的,当用户长时间未活动后,或者用户点击退出后,服务器将销毁Session。
  攻击者可以通过不停的发起访问请求,让Session一“直活”下去。
  当Session被加密保存在cookie里时,很多应用都是利用cookie的expire标签来控制Session的失效时间。cookie的expire时间是完全可以由客户端控制的。攻击者甚至可以为Session cookie增加一个expire时间。
  对抗这种Session保持攻击,一般为Session设置一个阈值。比如2天后强制Session过期。

单点登录(SSO)

  单点登录的英文全称是Single Sign On简称SSO。他希望用户只需登录一次,就可以访问所有系统。(腾讯QQ)
  SSO的优点在于风险及中化,就只需要保护这一个点。它把用户登录的过程集中在一个地方,在单点出设计安全方案,甚至可以考虑一些“重”的方法,比如双因素认证。
  SSO的缺点是,因为风险集中了,所以单点一旦被攻破了的话,后果会非常严重,影响的范围将涉及所有单点登陆系统。降低风险的办法是在一些敏感的系统里,再单独实现实现一个额外的认证机制。
  目前互联网上最为开放和流行的单点登录系统是OpenID。OpenID是一个开放的单点登录框架,他希望使用URI作为用户在互联网上的身份标识,每个用户(End User)将拥有一个唯一的URI。在用户登录网站(Relying Party)时,用户只需要提交他的OpenID(就是用户唯一的URI)以及OpenID的提供者(OpenID Provider),网站就会将用户定向到OpenID的提供者进行认证,认证完成后在重定向回网站。

小结

  在web应用中,用户登录之后,服务器端通常会建立一个新的Session用来跟踪用户状态。每个Session对应一个标识符SessionID,SessionID用来标识用户身份,一般是加密保存在cookie中。有的网站也会将Session保存在cookie中,以减轻服务器端维护Session的压力,围绕着Session可能产生很多安全问题,这些问题都是在设计安全方案时需要考虑到的。

详情请参考书籍
摘自:《白帽子讲Web安全》 — 吴翰清
© 版权所有,侵权必究。

浏览器安全

简介

  浏览器是互联网的最大入口,世界上绝大多数用户使用的互联网工具是浏览器。而·浏览器本身就是一个客户端,因此如果具备安全功能,就可以像安全软件一样对用户上网起到很好的保护作用。

同源策略

浏览器的同源策略,限制了来自不同源的document或脚本,对当前document读取或设置某些属性
  同源策略(Same Origin Policy)是一种约定,是浏览器最核心最基本的安全功能,如果缺少了同源策略,则浏览器的正常功能可能都会受到影响。可以说web是构建在同源策略的基础之上的,浏览器只是针对同源策略的一种实现。
  试想一下如果没有同源策略,可能a.com的一段JavaScript脚本时,也可以随意涂改b.com的页面,并显示在浏览器中。为了不让浏览器现实的页面发生混乱,浏览器提出了源(origin)这一概念,来自不同Origin的对象无法互相干扰。浏览器中JavaScript的同源策略:当JavaScript被浏览器认为来自不同源时,请求被拒绝。影响源的因素有:

  • host(域名或IP地址,如果是IP地址则看成一个根域名)
  • 子域名
  • 端口
  • 协议

  需要注意的是,对于当前页面来说,页面内存放的JavaScript文件的域并不重要,重要的是加载JavaScript页面所在的域是什么。
在浏览器中,<script><img><iframe><link>等标签都可以跨域加载资源,而不受同源策略的限制。这些带“src”属性的标签每次加载时,实际上是由浏览器发起了一次GET请求。不同于XMLHttpRequest的是,通过src属性加载的资源,浏览器限制了JavaScript的权限,使其不能读写返回的内容。
  对于浏览器来说,除了DOM、Cookie、XMLHttpRequest会受到同源策略的限制外,浏览器加载的一些第三方插件也有各自的同源策略。最常见的一些插件如Flash、Java Applet、Silverlight、Google Gears等都有自己的控制策略。同源策略一旦出现漏洞被绕过,也将带来非常严重的后果,很多基于同源策略制定的安全方案都将失去效果。

浏览器沙箱

  Sandbox即沙箱,计算机技术发展到今天,Sandbox已经成为泛指“资源隔离类模块”的代名词。Sandbox的设计目的一般是为了让不可信任的代码运行在一定的环境中,限制不可信任的代码访问隔离区之外的资源。如果一定要跨越Sandbox边界产生数据交换,则只能通过指定的数据通道,比如经过封装的API来完成,在这些API中会严格检查请求的合法性。
  但是浏览器安全是一个整体,在现今的浏览器中,虽然有多进程架构和Sandbox的保护,但是浏览器所加载的一些第三方插件却往往不受Sandbox管辖。比如近年来在Pwn2Own 大会上被攻克的浏览器,往往都是由于加载的第三方插件出现安全漏洞导致的。Flash、Java、PDF、.Net Framework 在近年来都成为浏览器攻击的热点。

恶意网址

  恶意网址拦截的工作原理很简单,一般都是浏览器周期性地从服务器端获取一份最新的恶意网址黑名单,如果用户上网时访问的网址存在于此黑取一份最新的恶意网址黑名单,如果用户上网时访问的网址存在于此黑名单中,浏览器就会弹出一个警告页面。
  常见的恶意网址分为两类:一类是挂马网站,这些网站通常包含有恶意的脚本如JavaScript或Flash,通过利用浏览器的漏洞(包括一些插件、控件漏洞)执行shellcode,在用户电脑中植入木马;另一类是钓鱼网站,通过模仿知名网站的相似页面来欺骗用户。

总结

  1. cookie 和session 的区别:
    • cookie数据存放在客户的浏览器上,session数据放在服务器上。
    • cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,考虑到安全应当使用session。
    • session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能,考虑到减轻服务器性能方面,应当使用COOKIE。
    • 单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie。
    • 所以个人建议:将登陆信息等重要信息存放为SESSION,其他信息如果需要保留,可以放在COOKIE中。
  2. CSP(内容安全策略)指的是内容安全策略,为了缓解很大一部分潜在的跨站脚本问题,浏览器的扩展程序系统引入了内容安全策略(CSP)的一般概念。这将引入一些相当严格的策略,会使扩展程序在默认情况下更加安全,开发者可以创建并强制应用一些规则,管理网站允许加载的内容,以白名单的机制对网站加载或执行的资源起作用。在网页中,这样的策略通过 HTTP 头信息或者 meta 元素定义。

摘自:《白帽子讲Web安全》 — 吴翰清
© 版权所有,侵权必究。

跨站脚本攻击

简介

  跨站脚本攻击(Cross Site Script),为与层叠样式表(Cascading Style Sheet,CSS)区分,在安全领域叫做XSS。XSS攻击通常指黑客通过“HTML”注入,篡改网页、插入恶意脚本。从而在用户浏览网页时,控制用户的浏览器。

XSS分类

根据效果的不同可以分为如下几类

  1. 反射型XSS
      反射型XSS也叫“非持久型XSS”(Non-persistnet XSS)。它只是简单的把用户输入的数据”反射”給浏览器。也就是说黑客往往需要诱使用户“点击”一个恶意链接才能攻击成功
  2. 存储型XSS
      存储型XSS也叫做“持久型XSS”(Persistent XSS),存储型XSS会把用户输入的数据“存储在服务器端”。这种XSS具有很强的稳定性。
  3. DOM Based XSS
      通过修改页面的DOM节点形成的XSS,被叫做DOM Based XSS。从效果上来说也是反射型XSS。(DOM:文档对象模型Document Object Model ,是一种用于HTML和xml文档的编程接口,他给文档提供了一种结构化的表示方法,可以改变文档的内容和呈现方式。DOM把网页和脚本以及其他的编程语言联系起来)

XSS攻击阶段

初探XSS Payload

  XSS攻击成功后,攻击者能够对用户当前浏览的页面植入恶意脚本,通过恶意脚本,控制用户的浏览器。这些用以完成各种具体功能的恶意脚本,被称为“XSS Payload”。XSS Payload实际上就是Javascript脚本(还可以是Flash或其他富客户端脚本),所以任何Javascript脚本能实现的功能,XSS Payload都能做到。

常见XSS Payload

  1. cookie劫持
    一个最常见的XSS Payload,就是通过读取浏览器的cookie对象,从而发起“cookie劫持”攻击。
    cookie中一般加密保存了当前用户的登陆凭证。cookie如果丢失,往往意味着用户的用户登录凭证丢失。换句话说,攻击者可以不通过用户密码,而直接登录进用户账户。
  2. 构建get与post请求
    一个网站的应用,只需要接受HTTP协议中的GET和POST请求即可完成所有操作。对于攻击者来说,仅通过JavaScript,就可以让浏览器发起这两种请求。
    • 攻击者可以通过插入一张图片来发起一个GET请求;
    • 攻击者可以构建一个form表单,然后自动提交这个表单;
    • 攻击者可以通过XMLHttpRequest发送一个POST请求;
    • 攻击者先获取到用户ID加密的值,然后构造完整的URL,并使用XMLHttpRequest发送一个GET/POST请求。
  3. 识别用户浏览器
    在很多时候,攻击者为了获取更大的利益,往往需要精准的收集目标个人信息,如:如果知道用户使用的浏览器、操作系统信息。攻击者就有可能实施一次精准的浏览器内存攻击,最终给用户电脑植入一个木马,XSS能够帮助攻击者快速达收集信息的目的。
    • 通过XSS读取浏览器的UserAgent对象,这个对象告诉我们很多客户端信息(OS版本、浏览器版本等),但是信息并不一定准确。
    • 攻击者可以根据不同浏览器的差别以及各自实现的一些独特的功能,同一浏览器不同版本之间的细微差别,编写JavaScript脚本分辨这些浏览器。
    • 巧妙地方法(参考书籍)
  4. 识别用户安装的软件
    知道了用户使用的浏览器、操作系统以后,进一步可以识别用户安装的软件。
    • 在IE中,可以通过判断ActiveX控件的classid是否存在,来推断用户是否安装了该软件。这种方法很早就被用于“挂马攻击”–黑客通过判断用户安装的软件,选择对应的浏览器漏洞,最终达到植入木马的目的;
    • 浏览器的扩展和插件也能够被XSS Payload扫描出来,以火狐为例:firebox的插件(plugins)列表存放在一个DOM对象中,通过查询DOM可以遍历所有插件,所以直接查询“navigator.plugins”对象,就能找到所有的插件了。火狐的扩展(通过检测扩展图标)
  5. CSS History Hack
    通过CSS,发现一个用户曾经访问过的网站。
  6. 获取用户的真实IP地址
    • 通过调用Java applet的接口获取客户端的IP地址。(在XSS攻击框架“Attack API”中有一个获取本地IP地址的api / 也可利用Java获取网络信息API,此方法需要写一个Java class,嵌入到当前页面中。 / metasploit)

XSS攻击平台

  安全研究者将不同功能的XSS Payload 封装起来,成为XSS攻击平台,这些攻击平台主要目的是为了演示XSS的危害。
  Attack API 是由安全研究者pdp所主导的一个项目,他总结了很多能够直接使用XSS Payload,并归纳为API的方式。
  BeEF 演示一个完整的XSS Payload攻击过程。
  XSS-Proxy 轻量级的XSS攻击平台,有助于理解XSS的原理和危害。

终极武器:XSS Worm

XSS 形成蠕虫,隐蔽性高且危害大

调试JavaScript

  想要写好XSS Payload 就要有很好的JavaScript功底。
Firebug :基于火狐浏览器的脚本调试工具。
IE8 Developer ToolS :主要用于调试IE。
Fiddler :是一个本地代理服务器,需将浏览器设置为本地代理服务器上网。他会监控所有的浏览器请求,并有能力在浏览器请求中插入数据。(支持脚本编程)
  HttpWatch :以插件的形式内嵌在浏览器中。在目标网站是https时会特别有用但是它不能调试JavaScript,仅仅是一个针对web的’sniffer’。
  **善于利用调试工具,在编写XSS Payload与分析浏览器安全时,会事半功倍。

XSS构造技巧

  • 利用字符编码,绕过安全检查。
  • 绕过长度限制,解决逻辑错误。
  • 使用<base>标签,伪造远程服务器地址。
  • 妙用window.name,对window.name赋值没有特殊字符限制,而且window对象是浏览器的窗体,而并非document对象,因此很多时候window对象不受同源策略的限制。

变废为宝:Mission Impossible

  往往一些被认为不可能实现攻击的漏洞,随着技术的发展,都可能会被利用到攻击中。

Flash XSS

  在flash中可以嵌入actionscript脚本,actionscript是一种非常强大和灵活的脚本,而且flash XSS往往被开发者忽视,注入flash变量的XSS,因为其问题出现在编译后的flash文件中,一般的扫描工具或者代码审计工具都难以检查。

JavaScript开发框架

  • Dojo
  • YUI
  • jQuery(目前最流行的JavaScript框架)
      除了需要关注框架本身安全问题外,开发者还要提高安全意识,理解并正确的使用开发框架。

XSS的防御

  流行的浏览器都内置了一些对抗XSS的措施,比如Firefox的CSP、Noscript扩展,IE8内置的XSS filter等等,而对于网站来说,也应该寻找优秀的解决方案,保护用户不被XSS攻击。

HttpOnly

  HttpOnly实现后,浏览器将禁止页面JavaScript访问带有HttpOnly属性的cookie。(主要解决cookie劫持问题)
一个cookie的使用过程如下:

  1. 浏览器向服务器发起请求(这时没有cookie)
  2. 服务器返回时发送Set-cookie头,向客户端浏览器写入cookie。
  3. 在该cookie到期前,浏览器访问该域下所有的页面,都将发送该cookie。
  4. HttpOnly是在Set-Cookie时标记的。
      现在IT业界给关键业务添加HttpOnly Cookie已经成为一种“标准”的做法。

输入检查

  输入检查的逻辑,必须放在服务器代码中实现。目前web开发的普遍做法,是同时在客户端JavaScript和服务器端代码中实现相同的输入检查,客户端的JavaScript输入检查,虽然很容易被攻击者绕过,但可阻挡大部分误操作的正常用户,从而节约服务器资源。
  在XSS防御上,输入检查一般是检查用户输入的数据中是否包含特殊字符,如<>、’、”等如果发现特殊字符,则将这些字符过滤或者编译。比较智能的输入检查,可能还会匹配XSS的特征,比如查找用户数据中是否包含了<script>javascript等,这种输入检查的方式,可以称为“XSS filter”。xss filter对语境的理解并不完整,不能过滤掉存在恶意脚本的URL,有时也会错误的过滤掉<、/等字符。

输出检查

  一般来说,除了富文本的输出外,在变量输出到HTML页面是时,可以使用编码或转义的方式来防御XSS攻击。

安全的编码函数

  • HtmlEncode :针对HTML代码的编码方式。
  • 在PHP中,有htmlentities()和htmlspecialchars()俩个函数可以满足安全要求。
  • JavaScriptEncode,需要使用转义字符\对特殊的字符进行转义,在对抗XSS时,还要求输出的变量必须在引号内。
    等。

auto-escape

  XSS攻击主要发生在MVC架构中的view层,大部分的XSS漏洞可以在模板系统中解决。但XSS的防御需区分情况对待。

正确的防御XSS

  XSS的本质还是一种“HTML注入”,用户的数据被当成了HTML代码一部分来执行,从而混淆了原来的语义,产生了新的语义。
  如果网站使用了MVC架构,那么XSS就发生在view层(在应用拼接变量到HTML页面时产生)。所以在用户提交数据处进行输入检查的方案,其实并不是在真正发生攻击的地方做防御。
根治XSS问题,列出所有XSS可能发生的场景,一一解决

  1. 在HTML标签中输出
     所有在标签中输入的变量,如果未做任何处理,都能导致直接产生XSS.
     防御方法是对变量使用HtmlEncode
  2. 在HTML属性中输出
     所有在属性中输入的变量,如果未做任何处理,都能导致直接产生XSS.
     防御方法是对变量使用HtmlEncode
  3. <script>标签中输出
     在<script>标签中输出时,首先应该确保输出的变量在引号中,这样攻击者需要先闭合引号才能实施XSS攻击。
     防御使用JavaScriptEncode
  4. 在事件中输出
     首先应该确保输出的变量在引号中,这样攻击者需要先闭合引号才能实施XSS攻击。
     防御使用JavaScriptEncode
  5. 在CSS中输出
      多样化,一般来说,尽可能禁止用户可控制的变量在“<style>标签”“HTML的标签的style属性”以及“CSS文件”中输出,如果一定要这样推荐使用OWASP ESAPI中的encodeForCSS()函数,其原理:除了字母、数字外的所有字符都被编译成16进制形式“\uHH”。
  6. 在地址中输出
      一般来说,在URL的path(路径)或者search(参数)中输出,使用URLEncode即可。URLEncode会将字符转换为“%HH”形式,比如空格就是“%20”,“<”符号是“%3c”。
      有一种情况,就是整个URL能够被用户完全控制,这时URL的protocal和host部分是不能够使用urlencode的,否则会改变URL的语义。
      一般来说如果变量是整个URL则应该检查变量是否已HTTP开头(如果不是则自动添加),以保证不会出现位协议类的XSS攻击。在此之后,在对变量进行urlencode,即可保证不会有此类的XSS发生了。

处理富文本

  时候网站需要允许用户提交一些自定义的HTML代码,称之为“富文本”,再过滤富文本时,事件应该严格禁止·标签采取白名单,避免黑名单,尽可能的禁止用户自定义CSS与style。

防御DOM Based XSS

  DOM Based XSS:将HTML代码写入了DOM节点,最后导致了XSS的发生。
  DOM Based XSS是从JavaScript中输出页面到HTML中,而之前研究的都是针对“从服务器应用直接输出到HTML页面”的XSS漏洞,因此在DOM Based XSS防御中应添加encode编码(两次:一次encode数据,一次encodeJavaScript)

总结

  往往一些知识远比你想象的复杂得多,所以纸上谈兵是不行的,要实际应用学习、尝试。
  XSS的本质还是一种“HTML注入”,用户的数据被当成了HTML代码一部分来执行,从而混淆了原来的语义,产生了新的语义。XSS攻击主要发生在MVC架构中的view层,大部分的XSS漏洞可以在模板系统中解决。但XSS的防御需区分情况对待。根治XSS问题,需列出XSS可能发生的场景,根据具体情况分析解决。

详情请参考书籍
摘自:《白帽子讲Web安全》 — 吴翰清
© 版权所有,侵权必究。

跨站点请求伪造

简介

  跨站点请求伪造(Cross Site Request Forgery,CSRF):攻击者首先在自己的域内创建一个页面,并伪造一个请求,然后诱使用户点击该页面,这样就以该用户的身份在第三方站点(攻击者构造的页面)执行了一次操作。

浏览器的cookie策略

  攻击者伪造的请求之所以能够被服务器验证通过,是因为用户的浏览器成功的发送了cookie的缘故。
  浏览器所持有的cookie分为两种:

  1. session cookie(又称临时cookie)
  2. third-party cookie(又称本地cookie)

  两者的区别在于third-party cookie是服务器在set-cookie时指定了expire时间,只要到了expire时间cookie就会失效。所以这种cookie会保存在本地。而session cookie则没有指定expire时间,直到关闭浏览器后,session cookie才失效,他保存在浏览器进程的内存空间中。
  有些浏览器,默认策略允许发送第三方cookie,所以能够成功发送用于认证的third-party cookie,CSRF攻击成功。而有些浏览器默认会拦截third-party cookie ,这样攻击者则需要精心构造攻击环境,比如诱使用户在当前浏览器先访问目标站点,使得session cookie有效,在实CSRF攻击。

P3P头的副作用

  P3P Header 是W3C制定的一项关于隐私的标准,全称是“the platform for privacy preferences”
  如果网站返回给浏览器的HTTP头中包含有P3P头,则在某种程度上来说,将允许浏览器发送第三方cookie,P3P头允许跨域访问隐私数据,从而可以跨域set-cookie成功。正因为P3P头目前在网站的应用中被广泛应用,因此在CSRF防御中不能依赖于浏览器对第三方cookie的拦截策略,不能心存侥幸。

构造get/post 请求

Flash CSRF

  Flash有很多方式发起网络请求,包括POST、getURL、loadvars等。

CSRF Worm

  即使没有XSS漏洞,仅仅是CSRF也能发起大规模蠕虫攻击。

CSRF的防御

验证码

  CSRF的攻击过程,往往在用户不知情的的情况下构造了网络请求,而验证码则强制用户必须与应用进行交互,才能完成最终请求,但是有些时候出于用户体验考虑,网站不能给所有的操作都加上验证吗,因此验证码只能作为防御SCRF的一种辅助手段。

Referer Check

  Referer Check在网络中常见的应用就是“防止图片盗链”。同理Referer Check也可以被用于检查请求是否来自合法的“源”。Referer Check的缺陷是:服务器并非什么时候都能取到Referer。
  很多用户处于隐私保护的考虑,限制了Referer的发送,在某些情况下,浏览器也不会发送Referer,(列:从https跳转至HTTP,出于安全考虑,浏览器也不会发送Referer);有些Flash的版本可以发送自定义Referer的头。因此我们无法依赖于Referer Check作为防御SCRF的主要手段,但是可以通过Referer Check来监控CSRF攻击的发生。

Anti CSRF Token

现在业界针对CSRF防御,一致做法是使用一个token。

CSRF的本质

  CSRF能够攻击成功的本质原因是:重要操作的所有参数都是可以被攻击猜测到的。攻击者只有预测出URL的所有参数与参数值,才能成功的构造一个伪造的请求。
  因此可以想到:把参数加密,或者使用一些随机数,从而让攻击者无法猜测到参数值,这是“不可预测性原则”的一种应用。
  在URL中,保持原参数不变,新增一个参数token,这个token的值是随机的,这样由于token的存在,攻击者无法在构造出一个完整的URL实施CSRF攻击。
  token需要同时放在表单和session中,再提交请求时,服务器只需验证表单中的token和用户session(或cookie)中的token是否一致,如果一致,则认为是合法请求;如果不一致,或者有一为空,则认为请求不合法,可能发生了CSRF攻击。

Token的使用原则

  token的生成一定要足够随机。
  可为token设置生命周期,可根据情况生成多个有效的token。
  使用token时应注意token的保密性。

安全防御的体系是相辅相成,缺一不可的。

详情请参考书籍
摘自:《白帽子讲Web安全》 — 吴翰清
© 版权所有,侵权必究。

访问控制

简介

  访问控制,或者说权限控制,广泛应用于各个系统中,抽象地说:都是某个主体(subject)对某个客体(object)需要实施某种操作(operation),而系统对这种操作的限制就是权限控制。
  在一个安全系统中,确定主体的身份是“认证”解决的问题;而客体是一种资源,是主体发起请求的对象,在主体对客体操作的过程中,系统控制主体不能无限制地对客体进行操作,这个过程就是访问控制。
  在web应用中,根据访问客体的不同,常见的访问控制可以分为:

  • 基于URL的访问控制
  • 基于方法(method)的访问控制
  • 基于数据的访问控制

垂直权限管理

  访问控制实际上是管理用户和权限之间的对应关系,现在应用广泛的一种方法是:基于角色的访问控制(Role-Based Access Control),简称RBAC。
  RBAC事先会在系统中定义出不同的角色,不同的角色拥有不同的权限,一个角色就是一个权限的集合。在系统验证权限时,只需要验证用户所属的角色,然后就可以根据该角色所拥有的权限进行授权了。Spring Security中的权限管理,就是RBAC模型的一个实现。Spring Security基于Spring MVC框架,它的前身是Acegi,是一套较为全面的web安全解决方案。
  在权限配置时,应当使用“最小权限原则”,并使用“默认拒绝”的策略,只对有需要的主体单独配置“允许”的策略。这在很多时候能够避免发生“越权访问”。

水平权限管理

  相对于垂直权限管理来说,水平权限问题处在同一个角色上。系统只验证能否访问数据的角色,即没对角色内的用户做细分,也没有对数据的子集做细分,因此缺少一个用户到数据之间的对应关系。由于水平权限管理是系统缺乏一个数据集的访问控制所造成的,因此水平权限管理又可以称之为“基于数据的访问控制”。  水平权限问题:
1.对于一个大型的复杂系统来说,难以通过扫描等自动化测试方法将这些问题全部找出来。
2.对于数据的访问控制,与业务结合得十分紧密。有的业务有数据级访问控制的需求,有的业务则没有。要清楚不同业务的不同需求,也不输是件容易的事。
3.如果在系统上线后再来处理数据级访问控制问题,则可能会涉及跨表、跨库查询,对系统的改动较大,同时也可能会影响到性能。

OAuth简介

  OAuth是一个在不提供用户名和密码的情况下,授权第三方应用访问web资源的安全协议。OpenID解决的是认证问题,OAuth则更注重授权。常见的OAuth应用场景,一般是某个网站想要获取一个用户在第三方网站中的某些资源或服务。

小结

  安全系统中的核心:访问控制。垂直权限管理:基于角色的访问控制;水平权限管理:基于数据的访问控制。

点击劫持(ClickJacking)

简介

  点击劫持(ClickJacking)是一种视觉上的欺骗手段,攻击者使用一个透明的、不可见的iframe。覆盖在一个网页上,然后诱使用户在该网页上进行操作,此时用户将在不知情的情况下点击透明的iframe页面,通过调整iframe页面的位置,可以诱使用户恰好点击iframe的一些功能按钮上。
   通过控制iframe的长、宽,以及调整top、left的位置,可以把iframe页面内的任意部分覆盖到任何地方。同时设置iframe的position为absolute,并将z-index的值设为最大,以达到让iframe处于页面的最上层,最后再通过设置opacity来控制iframe页面的透明程度,值为0是完全不可见。

Flash点击劫持

  攻击者通过flash构造出了点击劫持,此类攻击往往造成的危害更大。

图片覆盖攻击

  Cross Site Image Overlaying(XSIO): 通过调整图片的style使得图片能够覆盖所制定的任意位置。

拖拽劫持与数据窃取

  目前很多浏览器都开始支持Drag&Drop的API,对于用户来说,拖拽使得操作更加简单,浏览器中的拖拽对象可以是一个链接、也可以是一段文字、还可以从一个窗口拖拽到另一个窗口,因此拖拽是不受同源策略的影响的。
  拖拽劫持的思路是诱使用户从隐藏的不可见iframe中拖拽出攻击者希望得到的数据,然后放置攻击者能够控制的另一个页面中,从而窃取数据。

ClickJacking3.0: 触屏劫持

  从手机OS的角度来看,触屏实际上就是一个事件,手机OS捕捉这些事件,并执行相应动作。

防御ClickJacking

  针对传统的ClickJacking,一般是禁止跨域的iframe来防范。通常可以写一段JavaScript代码,已禁止iframe的嵌套,这种方法叫frame busting。,但是由于它是用JavaScript写的,控制能力并不是特别强,有很多方法可以绕过它。
  X-Frame-Options:一个http头,控制页面加载frame页面。

详情请参考书籍
摘自:《白帽子讲Web安全》 — 吴翰清
© 版权所有,侵权必究。

,