第十二章 Web框架安全
总的来说,实施安全方案,要达到好的效果,必须要完成两个目标:
1.安全方案正确、可靠;
2.能够发现所有可能存在的安全问题,不出现遗漏。1.MVC框架安全
MVC是 Model-View-Controller的缩写
一个优秀的安全方案,应该是:在正确的地方,做正确的事情。
在框架中实施安全方案,比由程序员在业务中修复一个个具体的bug,有着更多的优势。
首先,有些安全问题可以在框架中统一解决,能够大大节省程序员的工作量,节约人力成本。
由程序员一个个修补可能会出现遗漏。
在每个业务里修改安全漏洞,补丁的标准难以统一,从安全的有效性来说,更容易把握。2.模板引擎与XSS防御
从MVC架构来说,是发生在View层,因此使用“输出编码”的防御方法更加合理,
这意味着需要针对不同上下文的XSS攻击场景,使用不同的编码方式。
在当前流行的MVC框架中,View层常用的技术是使用模板引擎对页面进行渲染,
比如在“跨站脚本攻击”一章中提到的Django,就使用了Django Templates作为模板引擎。
Django Templates 默认是将auto-escape开启,所有的变量都会经过HtmlEncode后输出。
有时会缺乏来自安全专家的建议。所以在使用框架时,应该慎重对待安全问题,不可盲从官方指导文档。3.Web 框架与 CSRF 防御
CSRF 攻击的目标,一般都会产生写数据操作的URL,比如 增 删 改;
而读数据操作并不是CSRF攻击的目标,因为在CSRF的攻击过程中攻击者无法获取到服务器端放回的数据,
攻击者只是借用户之手触发服务器动作,所以读数据对于CSRF来说并不直接的意义。
因此,在web应用开发中,有必要对读操作和写操作 予以区分,比如要求所有的 写操作 都使用 HTTP POST
POST本身不能抵抗CSRF,但是POST的使用,对于保护token有着积极的意义,
而securituy token的私密性(不可预测性原则),是防御CSRF攻击的基础。
防御方法:
1.Session 中绑定token。
2.在form表单中自动填入token字段
3.在Ajax请求中自动添加token
4.在服务器端对比POST提交参数的token与Session中绑定的token是否一致,以验证CSRF攻击。
在Spring MVC 以及一些其他的流行Web框架中,并没有直接针对CSRF的保护,因此这些功能需要自己实现。4.HTTP Headers 管理
在web框架中,可以对HTTP头进行全局化的处理,因此一些基于HTTP头的安全方案可以很好地实施。
因此对于框架来说,管理好跳转目的地址是很有必要的。
一般来说,可以在两个地方做这件事情:
1.如果web架构提供统一的跳转函数,则可以在跳转函数内部实现白名单,跳转地址只能在白名单中;
2.另一种解决方案是控制HTTP的Location字段,限制Location的值只能是哪些地址。
有很多与安全相关的Headers,也可以统一在web框架中配置。
HttpOnly Cookie来说,它需要处处都加上这一属性,最好是在框架中解决,避免遗漏。5.数据持久层与SQL 注入
使用ORM框架对SQL注入是有积极意义的。我们知道对抗SQL注入的最佳方式就是使用“预编译绑定变量”。
在实际解决SQL 注入时,还有一个难点就是应用复杂后,代码数量庞大,难以把可能存在SQL注入的地方,
不遗漏地找出来,而ORM框架为我们发现问题提供了一个便携的途径。
使用Web 框架提供的功能,在代码风格上更加统一,也更利于代码审计。
6.还能想到什么
凡是在Web框架中可能实现的安全方案,只要对性能没有太大的损耗,都应该考虑实施。
在设计整体安全方案时,先建立威胁模板,然后再判断哪些威胁是可以在框架中得以解决的。
在设计Web框架安全解决方案时,还需要保存好安全检查的日志。
在设计Web框架安全时,还需要及时跟进最新的威胁。
7.Web框架自身安全
1.Struts 2 命令执行漏洞。
2.Django 命令执行漏洞
第十三章 应用层拒绝服务攻击
DDOS攻击被认为是安全领域中最难解决的问题之一,迄今为止也没有一个完美的解决方案。1.DDOS 简介
DDOS 又称为分布式拒绝服务
常见的DDOS攻击有SYN flood、UDP flood、ICMP flood等。
对抗SYN flood的主要措施有SYN Cookie/SYN Proxy、safereset等算法。
SYN Cookie的主要思路是为每一个IP地址分配一个Cookie,并统计每个IP地址的访问频率。
如果短时间内收到同一IP对应的Cookie,之后来自这个IP地址的包将被丢弃。
对抗DDOS的网络设备可以串联或者并联在网络出口处。2.应用层DDOS
应用层DDOS不同于网络层DDOS
1.CC攻击
当时黑客为了对抗绿盟的一款反DDOS设备开发了它。
CC攻击的原理简单,即对一些消耗资源较大的资源页面不断发起请求,到达耗尽服务器资源的目的。
爬虫把小网站直接爬死的情况时有发生,这与应用层DDOS攻击的结果很像。
应用层DDOS 攻击是针对服务器性能的一种攻击,那么许多优化服务器性能的方法,都或多或少有帮助。
2.限制请求频率
常见的DDOS防御手段是,在应用中针对每一个客户端做一个请求频率的限制。
通过IP地址与Cookie定位一个客户端,如果客户端的请求在一定时间内过于频繁,
则对之后来自该客户端的所有请求都重定向到一个出错的页面。
从架构来看,这段代码需要放在业务逻辑之前,才能起到保护后端应用的目的,
可以看做是一个”基层“的安全模块 。
3.道高一尺,魔高一丈
猎手代理可以不断跟换IP逃避基于IP的追踪。
1.应用代码要做好性能优化。合理使用内存缓存,而不是访问硬盘。释放资源,关闭无用数据库连接。
2.在网络架构上做好优化。善于利用负载均衡分流,CDN加速访问。
3.最重要的一点,限制每个IP地址的请求频率。3.验证码的那些事儿
验证码破解技术。
除了直接利用图像相关算法识别验证码外,还可以利用Web实现上可能存在的漏洞破解验证码。
验证码的验证过程,是比对用户提交的明文与服务器上的Session里保存的验证码明文是否一致。
曾经有验证码系统存在这样的漏洞,验证码消耗后SessionID未更新,
导致原来的SessionID一直有效,可以重复用一个验证码。
还有的验证码为了省事,提前把所有验证码生成好,全部以哈希过的字符串作为验证码图片的文件名。
在使用验证码时,则直接从图片服务器返回已经生成好的验证码,这种设计原本的想法是为了提高性能。
但是攻击在提前枚举完成所有验证码,构造出彩虹表,这样的验证码就会形同虚设。4.防御应用层DDOS
验证码的核心思想是识别人和机器
一种比较可靠的方法是让客户端解释一段JavaScript,并给出正确的运行结果。
除了人机识别外,还可以在Web Server做防御。比如 Apache 的 mod_qos 设置。5.资源耗尽攻击
除了CC攻击外,攻击者还可能利用一些Web Server的漏洞或设计缺陷,直接造成拒绝服务。
1.Slowloris攻击
其原理是以极低的速度往服务器发送畸形的HTTP请求。
此类攻击的本质,实际上是对有限资源的无限制滥用。
2.HTTP POST DOS
原理是发送HTTP POST包时,指定一个非常大的Content-Length值,
然后以很低的速度发包,保持住这个链接不放。
解决方案:可以使用Web应用防火墙,或者一个定制的Web Server安全模块
凡是资源有”限制“的地方,都可能发生资源滥用,从而导致拒绝服务,也就是一种“资源耗尽攻击”
3.Server Limit DOS
假如攻击者通过XSS攻击,恶意地往客户端写入了一个超长的Cookie,
则该客户端在清空Cookie之前,将无法再访问该域内的页面。解决方法需要调整Apache配置参数,LimitRequestFieldSize,
这个参数设置为0时,对HTTP包头的大小没有限制。6.一个正则表达式:ReDOS
利用正则表达式的缺陷,消耗资源,造成资源耗尽,称为ReDOS7.应用层拒绝服务攻击是传统的网络拒绝服务攻击的一种延伸,其本质也是对有限资源的无限滥用所造成的。
核心思路就是限制每个不可信任的资源使用者的配额。
第十四章 PHP安全
PHP的语法过于灵活,这也给安全工作带来了一些困扰。同时PHP也存在很多历史遗留的安全问题。
PHP语言的安全问题有其自身语言的一些特点。
1.文件包含漏洞
文件包含漏洞是代码注入的一种。
文件包含可能会出现在JSP/ASP/PHP 等语言中,常见的导致文件包含的函数如下。PHP:include(), include_once(),require(),require_once(),fopen(),readfile(),
JSP/Servlet:ava.io.File(),java.io.FileReader(),
ASP: include file, include virtual文件包含是PHP的常见用法,主要由四个函数完成:
include()
require()
include_once()
require_once()当使用这四个函数包含一个文件时,该文件将作为PHP 代码执行,PHP 内核并不会在意被包含的文件是什么类型。
这一特性,在实施攻击时将特别有用,比如以下代码,<?php include($_GET[test]); ?>
执行url urlurlurl?test=evil.txt
在执行漏洞URL,发现代码被执行了,要想成功利用文件包含漏洞,需要满足下面两个条件:
include()等函数通过动态变量的方式引入需要包含的文件,
用户能够控制该动态变量。1.本地文件包含
能够打开并包含本地文件的漏洞,被称为本地文件包含漏洞,简称为LFI。
PHP内核是用C语言写的,因此使用了C语言中的一些字符串处理函数。
在连接字符串时,0字节(\x00)将作为字符串结束符。
字符串截断的技巧,也是文件包含中最常用的技巧。
但在一般的应用中,0字节通常用户不会去使用,因此完全可以禁用0字节。
利用操作系统对目录长度的最大限制,也可以完成截断
。比如windows中的目录最长为256字节,Linux下则为4096字节,
超过最大长度之后的字符将被丢弃,即截断。
除了include()等4个函数外,PHP中能够对文件进行操作的函数都有可能出现漏洞。
虽然大多数不能执行代码,但是用来读取系统的敏感文件也是很危险的。 fopen()、fread()
文件包含漏洞能够读取敏刚文件或者服务器端脚本的源代码,从而为攻击者实施进一步攻击奠定基础。
目录遍历漏洞是一种跨越目录读取文件的方法,
但当PHP配置了open_basedir时,将很好地保护服务器,使得这种攻击无效。
open_basedir 的作用是限制在某个特定目录下 PHP 能打开的文件,
其作用与 safe_mode 是否开启无关。
要解决文件包含漏洞,应该尽量避免包含动态的变量,尤其是用户可以控制的变量。
一种变通的方法是,使用枚举方式使用动态变量。
2.远程文件包含
如果PHP 的配置选项 allow_url_include 为 ON 的话,
则 include/require 函数可以最大威力的发挥,可以加载远程
的恶意文件。这种漏洞称为远程文件包含漏洞(RFI)
甚至远程文件包含漏洞可以直接用来执行系统命令。
3.本地文件包含的利用技巧本地文件包含的利用技巧
本地文件包含漏洞,其实也是有机会执行PHP代码的,这取决于一些条件。
远程文件包含漏洞之所以能执行命令,就是因为攻击者能够自定义被包含的文件内容。
本地文件包含漏洞,按照同样的思路,只要找到一个可以控制内容的本地文件即可执行命令。
常用的技巧有以下几个,
1.包含用户上传的文件
2 包含 data:// 或 php://input 等伪协议
3. 包含Session 文件。
4. 包含日志文件,比如Web Server的 access.log
5. 包含 /proc/self/environ 文件。
6.包含上传的临时文件
7. 包含其他应用创建的文件,比如数据库文件,缓存文件、应用日志文件。
tips,如果日志文件比较多,可以在凌晨时攻击,成功率会提高。2.变量覆盖漏洞
14.2.1 全局覆盖变量
14.2.2 extract()变量覆盖
14.2.3 遍历初始化变量
14.2.4 import_request_variables变量
14.2.5 paarse_str()变量覆盖
14.2.6 小结
变量如果没有被初始化且被用户控制,则很可能会引发安全问题。
首先确保 register_globals=OFF.若不能自定义php.ini,则应该在代码中控制。
其次,熟悉可能造成变量覆盖的函数和方法,检测用户是否能控制变量来源。3.代码执行漏洞
离不开两个关键条件:第一是用户能够控制的函数输入;第二是存在可以执行代码的危险函数。
1.”威胁函数“执行代码
PHP中能够执行代码的方式远不止文件包含漏洞一种,
比如危险函数popen()、system()、passthru()、exec() 等都可以直接
执行系统命令。此外,eval()函数也可以执行PHP 代码。
还有一些比较特殊的情况,比如允许用户上传PHP代码,或者是应用写入到
服务器的文件内容和文件类型可以由用户控制,都可能导致代码执行。挖洞的过程,通常需要先找到危险函数,然后回溯函数的调用过程,
最终看在整个调用的过程中用户是否有可能控制输入。
2.”文件写入“执行代码
3. ”其他执行代码方式“
直接执行代码的函数 eval(),assert(),system(),exec(),shell_exec(),passthru(),escapeshellcmd()
文件包含 文件包含漏洞属于注入漏洞的一种,
需要高度关注的文件包含函数是 include()、include_once()、require()、require_once()
本地文件写入,file_put_contents()、fwrite()、fputs()等。
preg_replace() 代码执行,如果有/e修饰符则允许代码执行。
动态函数执行, 构造一个字符串作为函数名,调用函数。
Curly Syntax, 把代码写在花括号中。
回调函数执行代码
unserialize() 导致代码执行
4.定制安全的PHP环境
除了熟悉各种PHP漏洞外,还可以通过配置php.ini 来加固 PHP的运行环境
regitster_globals 建议将 regitster_globals=OFF
open_basedir 限制PHP只能操作指定目录下的文件。
allow_url_include 关闭此项,同时推荐关闭 allow_url_fopen
display_error 错误回显,建议关闭
log_errors 错误信息记录日志,建议开启。
magic_quotes_gpc 建议关闭,因为它滋生新的安全问题。
cgi.fix_pathinfo 需要关闭此项,避免出文件解析漏洞
session.cookie_httponly 建议开启
session.cookie_secure 若全站HTTPS 建议开启
safe_mode 在php6中除去此功能,建议关闭。
通常如果是共享环境需要禁用更多函数。
禁用一些类
XMLWriter
DOMDocument
DOMNotation
DOMXPath
SQLiteDatabase
SQLiteResult
SQLiteUnbuffered
SQLiteException
5.小结
本章先后介绍了PHP中一些特别的安全问题,比如文件包含漏洞,代码执行漏洞,
最终对如何制定一个安全的PHP环境给出了建议。第十五章 Web Server配置安全
web服务器安全,考虑的是应用部署时的运行环境安全。
这个运行环境包括Web Server、脚本语言解释器、中间件等软件,
这些软件所提供的一些配置参数,也可以起到安全保护的作用。本章讲讲Web服务器有哪些常见的运行时安全问题。
1.Apache 安全
Apache依然是Web Server领域的巨头,许多Web应用跑在Apache Httpd上。Web Server的安全我们关注两点:
一是Web Server本身是否安全,
二是Web Server是否提供了可使用的安全功能。Apache核心的高危漏洞几乎没有。Apache有很多官方与非官方的Module,
默认启动的Module出现过的高危漏洞
非常少,大多数的高危漏洞集中在默认没有安装或enable的Module上。因此,检测Apache的安全性首先是检测Module的安全性。
减少不必要的Module,及时升级Module在完成定制Apache安装包后,下一步就是指定一个单独的用户来运行Apache,
这通常需要为Apache单独建立一个user/groupApache以root身份或admin运行是非常糟糕的,
admin是管理机器时的身份权限还是比较高的,按最小权限原则,
应该单独分配一个账号仅仅是运行Web应用。高权限会带来2个可怕的后果
1.一旦入侵web成功时,将直接获得一个高权限的shell
2.应用程序本身将具备较高权限,当出现bug时,会带来较高的风险,
比如误删本地文件,杀死进程等。保存好Apache Log,比如实时发送到远程的syslog服务器上。
2.Nginx 安全
Nginx发展得很快,它的高性能和高并发处理能力,使得用户有更好的选择。
但是Nginx的默认安装版本爆发的漏洞要比Apache多,
就安全方面他们两的区别是,Apache的安全性更多关注Module的安全,
Nginx的安全性更多关注软件自身,及时升级即可。Nginx的高性能高并发需要更多的灵活配置,
但是对于大规模的DDOS,还是求助专业保护方案吧。3.jBoss 远程命令执行
jBoss是J2EE环境中一个流行的Web容器,
但是jBoss在默认安装时提供的一些功能却不太安全,
如果配置不得当,则可能直接造成远程命令执行。由于jBoss在默认安装时会有一个管理后台,叫做JMX-Console。
默认安装时访问JMX-Console是没有任何认证的。
加载war包方法有二:
一、通过DeploymentScanner远程加载一个war包。
二、通过JMX-Console提供的BSH Deployment 方法,同样也能部署war包。
BSH能够执行一次性的脚本,或者创建服务,这对黑客来说很有用。JMX-Console 为黑客提供了很大的方便,简单的Google hacking就可以得到很多漏洞站点。
建议删除了JMX-Console后台,jBoss的使用完全可以不使用它。
如果业务需要使用JMX-Console,
那就设置一个高强度的密码,同时不要对整个网络开发这个端口。4.Tomcat 远程命令执行
Tomcat与jBoss一样,默认也会允许在8080端口。
它提供的Tomcat Manager的作用与JMX-Console类似,
管理员也可以在Tomcat Manager中部署war包。值得庆幸的是,Tomcat部署war包得有manager权限。manager的权限要比tomcat用户权限大。
使用manager可以在后台上传war包。虽然Tomcat后台有密码保护,如果非必要建议删除了这个功能,
从安全的角度看,这增加了系统的攻击面。5.HTTP Parameter Pollution
通过Get或Post向服务器发起请求时,提交两个相同的参数,那么服务器会如何选择?
利用HPP特性,可以绕过一些服务器的逻辑判断。
这个攻击产生的原因是因为程序员不熟悉软件的这种功能,造成的误用。
HPP这一问题再次提醒我们,设计安全方案必须要熟悉Web技术方方面面的细节,才不至于有所疏漏。
从防护来看,由于HPP是一种功能,
只需在具体环境中注意服务器环境的参数取值顺序即可。6.小结
Web Server、Web容器是Web应用的载体,是基础,它们的安全与否将直接影响到应用的安全性。
在搭建服务器端环境时,需要注意遵循最小特权原则。
有些Web Server的默认配置会成为弱点,作为安全人员要熟知。
《白帽子讲Web安全 》 随手记(四)
最新推荐文章于 2022-07-31 02:06:07 发布