【51CTO.com独家翻译】想亲自击败黑客吗?OK,没问题,首先你要了解黑客是如何查找安全漏洞的,其次就是要了解黑客是如何利用Web应用程序漏洞的,最后就是了解他们是如何组织进攻的。本文将以一个漏洞百出的程序Jarlsberg为例,为大家讲解Web应用程序的攻防手段,全面解剖黑客的行径和应对办法。Jarlsberg是用Python编写的,因此略懂Python会帮助理解本文,但即使不懂也无所谓,因为漏洞和修复漏洞的方法基本上是与语言无关的。另外我们会涉及到黑盒黑客和白盒黑客,所谓黑盒黑客就是通过操纵输入字段或URL参数,观察Web应用程序的响应和变化,尝试找出让它出错的一种攻击手段,这里我们通常会查看HTTP/HTTPS请求和响应,推荐两款很棒的辅助工具Burp和WebScarab;所谓白盒黑客就是分析Web应用程序源代码,尝试找出bug并进行攻击的手段。
你完全可以根据本文介绍的内容搭建一个渗透测试环境,自己做做练习,以提升自己的技能,当然最重要的是通过学习达到举一反三,以后自己也能发现和修复漏洞,Jarlsberg的下载地址是http://jarlsberg.appspot.com/jarlsberg-code.zip,你也可以直接访问http://jarlsberg.appspot.com/start,AppEngine会自动为你创建一个新的Jarlsberg实例,每个实例都运行在独立的沙盒中,用唯一的ID进行标识,你可以随意展开攻击,你也可以将你唯一的URL分享给其它人进行攻击研究。
如果想在本地运行Jarlsberg,需要先安装Python 2.5,其它版本可能不行,执行Jarlsberg安装的命令如下:
|
用localhost:8008替换所有文件中的jarlsberg.appspot.com,并用分配给你的唯一ID替换默认ID 123。
如果是直接在AppEngine上创建的Jarlsberg实例,它有诸多限制,如不能访问和干扰其它Jarlsberg实例,资源使用也是有限制的,如果你捣鼓得Jarlsberg实例无法运行时,可以通过下面的URL进行重置,不过要注意的是所有历史数据都将被清除掉。
http://jarlsberg.appspot.com/resetbutton/123 |
注意用你自己的ID替换这里的123。
Jarlsberg各个源文件介绍:
◆jarlsberg.py是Jarlsberg Web服务器
◆jdata.py在数据库中存储默认数据,有一个管理员账号和两个默认用户
◆jtl.py是Jarlsberg模板语言
◆jsanitize.py是Jarlsberg保护自身HTML免受攻击的模块
◆resources/...目录下存放了所有模板,图片和CSS等文件
跨站脚本(XSS)
跨站脚本(XSS)指的是黑客通过网站漏洞在不受自己控制的网站内容(通常是HTML或JavaScript)中植入代码,当受害者浏览这样的网页时,植入的代码就会在受害者浏览器中执行,这样就可以顺理成章地窃取受害者与网站请求相关的个人信息。
在一个反射式XSS攻击中,攻击通常是嵌入在请求URL中,受害者浏览黑客构造的恶意URL时就被攻击了。在存储式XSS攻击中,攻击者将攻击代码保存在应用程序内,受害者浏览到这样的网页时就触发攻击代码的执行。
假设http://www.google.com/search?q=flowers这个URL返回的页面包含以下HTML片段:
|
查询参数q的值被嵌入到Google返回的页面中,如果www.google.com不做任何验证或忽略q,攻击者就可以构造一个类似下面这样的链接进行攻击尝试:
http://www.google.com/search?q=flowers+%3Cscript%3Eevil_script()%3C/script%3E |
接下来就是欺骗受害者点击这个链接,当受害者点击这个链接后,他的浏览器就会解析下面的代码:
|
浏览器就会执行evil_script(),于是受害者的浏览器状态和所有该域名对应的cookies都全部暴露出来了。
有时即使受害者不直接地点击恶意链接也会遭受攻击,例如,假设攻击者拥有www.evil.example.com域名,在页面中用
XSS挑战
一般说来,当其他用户浏览一个网页时,你可以让一段JavaScript代码在这个网页上执行,就说明它有XSS漏洞,一个简单有效的JavaScript函数是alert(),它会弹出一个窗口。
你可能认为插入一个alert消息不会有任何危险,但如果你能够插入alert(1),那么插入其它恶意代码,如eval(String.fromCharCode(...))也就没有问题了。
我们的挑战是发现Jarlsberg中的XSS漏洞,在哪些地方去找这个漏洞呢?一个是URL,另一个是存储的数据。因为XSS漏洞通常包含在那些不能正确处理非受信用户数据的应用程序中,发现XSS漏洞的方法通常是在输入字段中输入任意文字,再看响应的HTML代码变化。我们先来做一个简单的尝试。
文件上传XSS
任务:你能上传一个文件,让你在jarlsberg.appspot.com域名上执行任意脚本吗?
暗示:你可以上传一个包含脚本的HTML文件。
攻击:上传一个.html文件,包含以下脚本
|
修复:在一个独立的域名上托管内容,这样脚本就不能访问你域名上的任何内容了,也就是说,我们应该用username.usercontent.example.com或username.example-usercontent.com这样的域名代替example.com/username托管用户的内容,另外还要注意不要让用户可以注册注入wwww等容易引起钓鱼攻击的用户名。
反射式XSS
有趣的是,有些浏览器内置了防反射式XSS攻击,如IE和Chrome,另外也有一些浏览器扩展,如NoScript也能提供这样的保护,为了解决这个问题,Jarlsberg特意在每个HTTP响应头中加入了X-XSS-Protection: 0,让IE可以识别,如果是Chrome,你可以通过disable-xss-auditor启动参数禁用反射式XSS保护。
如果你使用的是Firefox,并安装了NoScript扩展,请将jarlsberg.appspot.com列入允许列表,如果还不行,最好换个其它浏览器。
也许你认为既然浏览器有了保护能力,为什么还需要担心这种攻击呢?其实浏览器并不能完全准确地实施保护,因为它不了解你的应用程序,聪明的黑客是可以绕过这层保护机制的,真正的保护是从应用程序源头杜绝XSS漏洞。
任务:找出一个反射式漏洞,我们希望通过点击一个URL执行一个脚本。
提示1:这个URL是什么呢?
http://jarlsberg.appspot.com/123/invalid |
提示2:在URL中最危险的字符是<和>,尝试输入下面的URL:
以上的URL是通过不同语言风格构造的<和>,直接在浏览器地址栏输入<和>是一样的,浏览器会自动编码,然后查看返回的HTML代码,研究服务器对这些URL的响应。
攻击:创建下面这样一个URL,让受害者点击它
http://jarlsberg.appspot.com/123/> |
修复:你需要绕过显示在错误信息中的用户输入,错误信息是使用error.jtl显示的,但没有绕过模板,提供消息的模板部分是{{message}},添加:text绕过用户输入。
|
杜绝这个漏洞的最好办法是避免所有默认的输出,仅显示原始HTML。#p#
存储式XSS
任务:现在我们来寻找一个存储式XSS,我们想做的是在Jarlsberg内部放置一小段代码,其它人访问时就执行它。
提示1:放置下面这段代码看看效果
|
将脚本嵌入到文档有很多方式。
提示2:黑客不会限制他们自己验证HTML语法,试试一些无效的网页,看看会返回什么,你可能需要试验一下,以便找到下手的地方。
攻击:嵌入下面任意一种代码片段
| alert(1)hello
修复:在jsanitize.py文件_SanitizeTag部分中,将onmouseover添加到disallowed_attributes列表中,可以预防片段1的攻击。
但这种修复方法不彻底,因为检查不允许的属性时是区分大小写的,而HTML则不区分大小写,正确的做法是:
1、将输入解析为一个中间DOM结构,然后以良好的格式输出;
2、为允许的标记和属性使用严谨的白名单;
3、对允许的URL和CSS属性采用严格的净化处理。
在条件允许的情况下,最好使用一个HTML净化器。
通过HTML属性进行存储式XSS
任务:你也可以在HTML属性上注入值来实施XSS,如通过设置配置文件中的颜色值植入一段脚本。
提示1:颜色是使用style='color:color'渲染的,试试在颜色名中包含一个单引号字符的效果。
提示2:你可以插入一个HTML属性执行一个脚本。
攻击:使用的下面的代码设置颜色
red' onload='alert(1)' onmouseover='alert(2) |
当你鼠标移到它上面时就触发了攻击。
修复:我们需要一个正确的文字转义程序,有效地规避单引号和双引号,将下面的函数增加到jtl.py,用它替代cgi.escape。
def _EscapeTextToHtml(var): """Escape HTML metacharacters. This function escapes characters that are dangerous to insert into HTML. It prevents XSS via quotes or script injected in attribute values. It is safer than cgi.escape, which escapes only <, >, & by default. cgi.escape can be told to escape double quotes, but it will never escape single quotes. """ meta_chars = { '"': '"', '\'': ''', # Not ' '&': '&', '<': '<',< '>': '>', } escaped_var = "" for i in var: if i in meta_chars: escaped_var = escaped_var + meta_chars[i] else: escaped_var = escaped_var + i return escaped_var |
但这种修复方法仍然不完美,颜色值仍然存在漏洞。
提示1:有些浏览器允许你在样式表中包含脚本。
提示2:最容易遭到利用的浏览器是IE,因为它支持动态CSS属性(也叫做CSS表达式)。
攻击方法:使用下面的代码替换颜色值
expression(alert(1)) |
虽然其它浏览器不支持动态CSS属性,但一样存在其它危险的CSS属性,如Mozilla的-moz-binding。
修复办法:我们需要将颜色值净化为一个真正的颜色值,最好的办法是增加一个新的输出净化格式给jtl,例如,我们可能会书写{{foo:color}}确保foo被安全地用作一个颜色,下面这个函数可以用来净化。
|
你可以为字体大小,字体,URL等做类似的净化,它对输入验证也很有帮助,如果有人输入了一个无效值,你可以立即提醒或是拒绝他,但光做输入验证还不够,如果你的验证代码本身也有漏洞,或是浏览器暴出新的攻击向量,你不得不返回重新清洗之前全部输入的值,或是增加输出验证。#p#
通过Ajax进行存储式XSS
任务:使用Jarlsberg Ajax代码中的bug找出一个XSS攻击点,当你点击页面刷新链接时触发攻击。
提示1:在http://jarlsberg.appspot.com/123/feed.jtl上运行curl查看结果,或者在浏览器中输入这个URL,查看返回结果的HTML源代码,你会看到每个用户的第一个微博包含在响应包中,然后整个响应包在客户端接受评估,最后将微博内容插入到文档中,你能够在微博内容中加入点什么使其与预期的结果有所不同吗?
提示2:在你的微博内容中添加一个双引号试试。
利用方法:将下面的代码插入到你的微博内容中。
|
JSON看起来应该象
_feed(({..., "Mallory": "snippet", ...})) |
代替后看起来象
|
注意,每个下划线部分都是一个独立的表达式,这个攻击是不可见的,因为使用了
修复办法:首先,在服务器端,原文在JSON响应中呈现时转义就不正确,虽然模板声明了{{snippet.0:html}},但仍然不够,原文将被插入到DOM节点的内部HTML中,因此HTML必须进行净化,但净化后的原文将被插入到JavaScript中,单引号和双引号将被转义,给jtl增加{{...:js}}支持是不够的,我们也需要支持{{...:html:js}}。
如果要转义单引号和双引号,分别使用\x27和\x22,用和"替代它们是不正确的,因为JavaScript是不能识别和"的。
其次,在浏览器中,Jarlsberg使用JavaScript的eval转换JSON,通常情况下,使用eval非常危险,我们应该使用JSON解析器确保字符串不包括任何不安全的内容,json.org就提供了JSON解析器下载。
通过Ajax实施反射式XSS
任务:使用Jarlsberg的Ajax功能,找出一个URL,点击它就执行一个脚本。
提示1:Jarlsberg刷新用户的微博页面时,使用了:
http://jarlsberg.appspot.com/123/feed.jtl?uid=value |
结果是脚本
_feed((["user", "snippet1", ... ])) |
提示2:这里使用了不同的漏洞,但和前面的反射式XSS利用方法是类似的。
攻击方法:创建类似下面这样的URL,诱使受害者点击它
|
它们被翻译为
_feed(([""])) |
这个bug让Jarlsberg返回了所有文件类型为text/html的jtl文件。
修复办法:需要确保JSON内容不会当作HTML解析,需要修改{{...:js}},用JavaScript转移字符\x3c和\x3e进行替换,在JavaScript中用\x3c和\x3e分别替换<和>总是安全的,注意,用HTML转移字符<和>也是不正确的。
同时,你还应该设置响应的内容类型,这里我们使用application/javascript。
此外,Jarlsberg也未设置内容编码,浏览器会尝试根据文档内容进行猜测,攻击者也可以利用这个漏洞欺骗浏览器,如攻击者使用UTF-7编码欺骗浏览器,于是就可以嵌入+ADw-script+AD4-脚本标记,在UTF-7中,+ADw-和+AD4-分别代表<和>,因此不仅要设置正确的内容类型,编码也要设置,设置方法和HTML类似,如:
Content-Type: text/html; charset=utf-8 |
虽然没有一种万能的方法来防御XSS漏洞,但仍然有一些重要的原则应该遵守。
1、首先确保你弄明白了问题;
2、尽可能通过模板功能净化,尽量不要直接在代码中使用转义字符进行净化;
3、实施XSS相关的测试;
4、不要试图自己写模板库。 #p#
客户端状态操纵
用户与Web应用程序交互是通过浏览器进行的,点击一个按钮或是提交一个表单,浏览器都会将请求发送给Web服务器,因为浏览器很容易被黑客控制,因此Web服务器不应该相信任何浏览器发来的数据。
写一个Web应用程序也不相信任何数据似乎不太可能,也没那个必要,如用户提交一个表单表示他想购买的商品列表,这时信任它也无妨,但如果提交的表单也包含价格信息,那就应该谨慎了。
特权提升
任务:将你的帐户升级成管理员
提示:一般用户和管理员都使用editprofile.jtl编辑自己的配置信息,如果你不是管理员,这个页面看起来会有所不同。
攻击方法:使用下面任意一个URL都可以将你的普通帐户转换成管理员
|
第二个URL可以通过替换username将任何一个普通用户升级成管理员。
由于Cookie的问题,你可能看到帐户状态不是立即显示为管理员,只要你注销重新登录就可以了。
修复办法:这里的bug是服务器端代码缺少身份验证引起的,正确的做法是在服务器端检查授权。
Cookie操纵
因为HTTP协议是无状态的,Web无法知道某两个请求来自同一个用户,就是在这种背景下,Cookie诞生了,当一个网站在HTTP响应中引入Cookie后,浏览器在下一次请求时就会自动发送Cookie,网站可以使用Cookie保存会话状态,Jarlsberg使用Cookie记住登录用户的身份,因为Cookie是保存在客户端的,因此很容易受到操纵,Jarlsberg为了保护Cookie专门增加了一个散列,遗憾的是,实施攻击不一定需要破坏散列。
任务:让Jarlsberg为你生成其它用户的Cookie。
提示:Jarlsberg的Cookie格式如下
hash|username|admin|author |
当你登录时Jarlsberg为你生成一个Cookie。
攻击方法:使用“foo|admin|author”作为用户名创建一个新用户,然后用它登录,Jarlsberg产生“hash|foo|admin|author||author”Cookie,于是foo成为管理员,因此这也算是一种特权提升攻击。
修复办法:由于系统对用户名没有任何字符限制才导致攻击可以得逞,因此在构造Cookie时要对用户名进行转义,如果与预期的模式不能匹配,就拒绝为其产生Cookie。
跨站请求伪造(XSRF)
前面我们曾提到,如果用户提交的表单仅仅表示他希望购买的商铺列表,那信任这些数据也无妨,只要确保是这个用户提交的数据即可,如果你的网站有XSS漏洞,即使你已经实施了XSS保护,但还有另一种攻击需要保护,那就是跨站请求伪造。
浏览器向网站发送请求时,它也会将该网站的Cookie一并发送,Web服务器不会区分请求是否有用户行为(如用户点击提交按钮,或是页面中嵌入的一个图片),因此,当网站接收到一个请求要执行一些动作时(如删除邮件,修改联系人信息等),Web服务器不知道这些行为是否是用户真正的本意,即使请求中包含了Cookie也证明不了,攻击者可以利用这个漏洞欺骗服务器,执行非用户本意想要执行的动作。
例如,假设Blogger有XSRF漏洞,在页面上有一个删除按钮,其对于的URL是:
http://www.blogger.com/deleteblog.do?blogId=BLOGID |
攻击者Bob在他自己的网页http://www.evil.example.com中嵌入下面的HTML代码:
http://www.blogger.com/deleteblog.do?blogId=alice's-blog-id" |
如果受害者Alice登录到www.blogger.com,当她浏览上面的页面时,会发生:
◆她的浏览器从http://www.evil.example.com载入页面,之后浏览器尝试载入页面中嵌入的所有对象,包括这里的img对象;
◆浏览器向http://www.blogger.com/deleteblog.do?blogId=alice's-blog-id产生一个请求,载入图片,由于Alice已经登录到Blogger,她就有一个Blogger Cookie,浏览器也会在请求中发送该Cookie;
◆Blogger验证Cookie是一个有效的会话Cookie,然后验证alice's-blog-id对应的博客是否属于Alice,如果是就删除该博客;
◆Alice不知道是什么原因造成自己的博客就没有了。
在这个攻击示例中,因为每个用户有他们自己的博客id,攻击目标是单个用户,但在很多时候,类似这样的攻击可以针对批量用户,批量数据。
XSRF挑战
这里的目标是找到一个方法代表登录Jarlsberg的用户执行账号修改行为,但真正的用户并不知情,假设你可以正常访问一个网页。
任务:找到一个方法让某个人删除他们的Jarlsberg微博内容。
提示:删除一个微博内容用到的URL是什么?
攻击方法:诱使用户访问产生下列请求的页面
http://jarlsberg.appspot.com/123/deletesnippet?index=0 |
为了达到更好的迷惑性,我们将Jarlsberg图标加在这个URL上。
修复办法:我们首先应该修改/deletesnippet通过POST请求工作,因为这是一个状态改变行为,按照HTML形式,将method='get'修改为method='post'。在服务器端,GET和POST请求除了调用不同的处理程序外,它们都一样,例如,Jarlsberg使用Python的BaseHTTPServer为GET请求调用do_GET,为POST请求调用do_POST。
但仅仅修改为POST并是完美的修复方法,只能说使用POST是正确的做法,因为GET请求是可以重新发出的,而POST请求是不能重新发出的,我们需要传递一个唯一的,不可预知的认证令牌action_token给用户,可以使用用户Cookie和当前时间戳的哈希值,在所有改变状态的HTTP请求中作为一个附加HTTP参数包含这个令牌,使用时间戳的目的是可以让过期的令牌失效,即使它被泄露出去,因时效性问题,引起的影响也会很小。
在处理一个请求时,Jarlsberg应该重新生成令牌,与请求提供的令牌进行比较,如果相同就执行行为,否则就拒绝它,生成和验证令牌的函数如下:
|
很遗憾,这个函数仍然有问题。
因为令牌中包含时间,我们必须防止它永久有效,如果攻击者获得一个令牌的拷贝,他可以在24小时内反复使用它就麻烦了,令牌的过期时间应尽可能设得短一点,即使请求被攻击者拦截,也只能攻击一次,攻击者不能反复利用这个请求,令牌应该和特定的状态改变行为联系起来,如一个页面的URL,对于非常长的行为,如编辑一个微博,页面上的脚本可以查询服务器更新令牌。
XSRF漏洞的存在让攻击者可以轻易构造一系列请求,为了阻止这种攻击,需要引入一些不可预知的值,让攻击者不是那么容易构造伪造的请求,有些应用程序框架内置了XSRF保护,它们会在每个响应中包含一个唯一的令牌,并且会验证每个POST请求。#p#
跨站脚本置入(XSSI)
浏览器可以阻止一个域名下的网页读取另一个域名下的网页,但它不能阻止一个域名下的网页引用另一个域名下的资源,特别是它们允许引用另一个域名下的图片,执行另一个域名下的脚步,引用的脚本无自己的安全上下文,它完全依赖引用它的页面的安全上下文,例如,如果www.evil.example.com包含了一个托管在www.google.com上的脚本,这个脚本就运行在evil上下文而不是google上下文中,因此这个脚本中包含的任何用户数据都可能被泄露。
XSSI挑战
任务:使用XSSI找到一个阅读他人私有微博的方法。
在另一个网站上创建一个网页,在这个网页中插入一些代码,使其可以访问你的私有微博内容。
提示1:将下面的代码添加到你的HTML页面,你可以从另一个域名运行脚本
http://jarlsberg.appspot.com/123/...">> |
提示2:feed.jtl是一个脚本。
攻击方法:将下面的代码插入一个HTML文件中
|
当feed.jtl中的脚本被执行时,它运行在攻击者页面的上下文中。
修复办法:首先使用XSRF令牌确保包含机密数据的JSON结果只会返回给你自己的页面,其次,你的JSON响应页面应该只支持POST请求,防止通过脚本标记载入脚本,第三,要确保脚本是不可执行的,标准的做法是增加一些不可执行的前缀,如])}while(1);,相同域名下的脚本可以读取响应的内容,自动卸掉前缀,但运行在另一个域名的脚本就不能读取响应的内容。
路径遍历
一般来说,一个Web应用程序包含很多静态文件,如图片,CSS,JS文件等,正常情况下有些文件的访问是要经过验证的,但如果不小心,可能导致攻击者越权遍历整个网站的目录,例如,在Windows和Linux下,..代表父目录,如果你能在访问路径中注入../,那就意味着你可以访问到父目录中的文件。
如果攻击者知道你的文件系统结构,那么他们可以构造一个URL遍历网站目录以外的目录,甚至是/etc,例如,如果Picasa有路径遍历漏洞,Picasa使用Unix类系统,那么下面的URL将可以窃取到系统密码文件:
http://www.picasa.com/../../../../../../../etc/passwd |
通过路径遍历暴露信息
任务:找到一个方法从Jarlsberg服务器读取secret.txt。
这种攻击在许多情况下不是必需的,人们安装程序时往往不会修改默认位置,因此攻击者首先会尝试默认路径遍历。
提示1:这不是一个黑盒攻击,因为你需要知道secret.txt文件是否存在,它位于哪里,以及Jarlsberg将它的资源文件存储在哪里,你不需要查看任何源代码。
提示2:服务器如何知道哪个URL表示资源文件,你可以使用curl或Web代理构造一个请求URL。
攻击方法:通过下面的URL窃取secret.txt
http://jarlsberg.appspot.com/123/../secret.txt |
有些浏览器,如Firefox和Chrome,优化了URL中的../输出,但这不能提供任何安全保障,因为攻击者可以使用类似curl、Web代理或是没做这种优化的浏览器等工具。
修复办法:我们需要阻止访问资源目录以外位置的文件,验证文件路径的办法有点麻烦,因为有很多种隐藏../或~等路径元素的办法,最佳的保护办法是只服务特定的资源文件,可以将其硬编码进你的应用程序,只接收访问这些文件的请求,如果非要做文件路径验证,那也只能对最终路径进行验证,而不是对URL进行验证,因为URL中的字符是可以转义的。
通过路径遍历进行数据篡改
任务:找到一个办法替换掉处于运行中的Jarlsberg服务器上的secret.txt。
提示:如果我以用户brie登录并上传一个文件,服务器会将它存放在哪里?你可以欺骗服务器将上传文件替换掉../secret.txt吗?
攻击方法:创建一个新用户..,上传你的secret.txt,你也可以创建一个名叫brie/../..的用户来达到同样的目的。
修复办法:需要对用户名进行危险字符转义,我们应该限制用户名允许的字符,另外还需要转换大小写,因为Windows下的文件名是不区分大小写的,而Jarlsberg要区分。
拒绝服务(DoS)
拒绝服务攻击就是让服务器超负荷处理伪造的请求,使其无法为正常的请求提供服务,保护应用程序防止这种攻击超出了本文的范围,对Jarlsberg的DoS攻击将会转化为对App Engine的攻击。下面的任务是找出Jarlsberg中可以用来执行DoS攻击的bug。
DoS – 服务器停机攻击
最简单的攻击办法就是让服务器停机。
任务:找出让服务器停机的办法。
提示:管理员可以关闭服务器,管理页面是manage.jtl。
攻击方法:向http://jarlsberg.appspot.com/123/quitserver发送一个请求。
修复办法:只允许管理员访问/quitserver。
|
DoS – 服务器超负荷攻击
任务:找到一个让服务器处理一个请求就超负荷工作的方法。
提示:可以上传一个模板来实现,每个页面都包含menubar.jtl模板。
攻击方法:创建menubar.jtl文件,包含
[[include:menubar.jtl]]DoS[[/include:menubar.jtl]] |
使用路径遍历攻击将其上传到resources目录。
修复办法:和前面一样,实现路径遍历保护。
代码执行
如果攻击者能远程在你服务器上执行任意代码,那表示你玩完了,遗憾的是目前也没有一个万能的方法来预防远程代码执行,因此只有靠程序本身进行验证。
攻击方法:通过修改jtl.py,置入恶意代码,然后上传替换掉原来的jtl.py,通过http://jarlsberg.appspot.com/123/quitserver让服务器关机,等它重启后,置入的恶意代码就开始工作了。
Jarlsberg也有这个漏洞,因为Jarlsberg目录允许写入文件,这违背了最小权限原则。
修复办法:修复前面两个漏洞即可。
配置漏洞
黑客们都非常熟悉常用应用系统的默认设置,如按照目录,默认管理员用户和密码等,如果配置不当,也相当于暴露了系统的漏洞。我们常见的如调试选项默认被开启,默认的状态页,堆栈转储跟踪等都属于配置漏洞。
信息泄露
比如通过http://jarlsberg.appspot.com/123/dump.jtl就可以暴露出Jarlsberg的数据库内容,唯一的办法就是删除/dump.jtl,如果非要开启调试功能,那最好只允许管理员访问,同时开启IP地址访问限制。
通过暴库,我们可以获得系统用户名和密码,因此密码最好使用哈希值保存。
虽然我们可以删除原始的dump.jtl,但Jarlsberg有文件上传漏洞,因此攻击者可以构造自己的dump.jtl,我们只能限制用户上传,或是用户上传的文件不能和Web应用程序位于同一位置,另外也可以限制上传的文件类型。
总结
Web应用程序的安全涉及的内容很多,从代码到配置都必须引起重视,可能一个小小的失误就会导致整个服务器被攻击者控制,安全从来就是相对的,攻防技术是不断发展和变化的,加强学习和实战是提高的唯一办法。
【51CTO.COM 独家翻译,转载请注明出处及作者!】
【编辑推荐】