赞
踩
- 中国黑客发展分为三个阶段:启蒙时代、黄金时代、黑暗时代
- 启蒙时代
- :20世纪90年代,也正是中国互联网刚刚起步阶段,热爱新兴技术的青年收到国外黑客技术影响,开始研究安全漏洞。启蒙时代的黑客大多由于个人爱好走上这条路,好奇心和求知欲是他们前进的动力,没有任何利益瓜葛。这个时期的中国黑客们通过互联网,看到了世界,因此与西方发达国家同期诞生的黑客精神是一脉相传的,他们崇尚分享、自由、免费的互联网精神,并热衷于分钟自己的最新研究成果。
- 黄金时代
- :以2001年中美黑客大战为标志(感兴趣的同学可以百度一下“中美黑客大战”,相信大家都记得2001年中国飞行员王伟为了捍卫国家主权,被美国侦察机撞毁事件,起因正是这件事,这次事件中,中国黑客空前团结,与美国黑客开展了一场激烈的黑客大战,非常轰动,也这是世界第一次黑客大战),这次事件大大推动了中国黑客的发展,崛起了一批黑客、红客联盟,也让黑客这个特殊群体一下吸引了社会的眼球,黑客圈子所宣扬的黑客文化和黑客技术的独特魅力也吸引了无数的青少年走上黑客这条道路。这次事件之后,各种黑客组织如雨后春笋般冒出,他们普遍的特点是:年轻、有活力、充满激情,但技术上也许还不够成熟。此时,黑客圈子里贩卖漏洞、恶意软件的现象开始升温,因为黑客群体良莠不齐,开始出现以赢利为目的的攻击行为,黑色产业链逐渐成型。
- 黑暗时代
- :这个时代大概从几年前开始一直持续到现在(PS. 是哪一年呢?个人觉得大概是07年底左右开始吧),也许还将继续下去。这个时期的黑客组织也遵循社会发展规律,优胜劣汰,大多数黑客组织没有坚持下去,20世纪非常流行的黑客技术论坛也越来越没有人气,最终走向没落。所有门户型的漏洞披露站点,再也不公布任何漏洞相关技术细节。随着安全产业发展,黑客的功利性越来越强,黑色产业链开始成熟。在20世纪技术还不太成熟的黑客们,凡是坚持下来的,都已经成为安全领域的高级人才,要么,在安全公司贡献自己的专业技能,要么带着非常强的技术进入黑色产业。此时期的黑客群体因为互相之间缺失信任,已经不再具有开放和分享的精神,最纯粹的黑客精神实质上已经死亡。整个互联网笼罩在黑色产业链的阴影之下,每年数十亿经济损失和数千万网民受害,黑客精神的死亡,让我们没有理由不把这个时代称为黑暗时代。也许,黑客精神所代表的Open、Free、Share,真的一去不复返了!
PS:以上SQL注入、XSS跨站、CSRF跨站伪请求伪造等名词,不明白意思没关系,先熟悉他们的名字吧,知道它们是WEB应用安全的重要敌人就行,后面慢慢讲解他们具体是什么,有什么危害,怎么防范。
"No Patch for stupid"即“最大的漏洞就是人”,所以安全问题是一直存在的, 安全的本质是信任问题,数据来源不可信,这是安全的一个原则 安全是一个持续的过程,不断的升级与改善 互联网安全的核心问题,是数据安全的问题。 安全的3要素:CIA 机密性(Confidentiality):要求数据内容不能被泄露,常见实现技术为加密。 完整性(Integrity):要求数据内容是完整的,没有被篡改,常见实现技术为数字签名。 可用性(Availability):要求保护资源是“随需而得”,例如DOS(Denial of Service)攻击,是常见的破坏可用性的方法 扩展:可审计性、不可抵赖性 安全的评估:1、资产等级划分:2、威胁分析: Threat:可能造成危害的来源;Risk:可能会出现的损失。这两个概念要分清。 微软提出的STRIDE模型:3、风险分析:Risk = Possibility * Damage Potential 微软提出的DREAD模型:当然,所有的这些模型都是辅助作用,模型可能会有更新,根据不同的产品模型也有不同,做决策的是人。 4、设计安全方案:一些原则: 1、Secure by default 原则:也可以归纳为白名单、黑名单的思想,最小权限原则。 2、纵深防御原则(Defense in depth): a、不同层面,不同方面实施安全方案安全和业务并不冲突,安全也应该是产品的一种属性,一个从未考虑过安全的产品,是不完整的b、在正确的地方做正确的事,比如说XSS,只需要在输出的时候进行处理即可3、数据库与代码分离原则 4、不可预测性(Unpredictable):比如说id的生成,自增长就很容易被预测,往往需要用到加密、随机数算法、哈希算法,常见的常见为预防CSRF的时候采用token
浏览器安全: 同源策略(Same Origin Policy):Web是构建在同源策略的基础上的,同源策略现在离来自不同源的“document”或者脚本,对当前“document”的读写权限。浏览器沙箱: Sandbox,资源隔离类模块,其目的是让不可信的代码运行在一定的环境里,限制不可信的代码访问隔离区之外的资源;如果一定需要跨越sandbox便捷进行交互,则通过安全的API来完成。Chrome和IE都采用了Sandbox技术。 恶意网址拦截: http://www.phishtank.com/ 免费提供恶意网址黑名单的组织 IE、Chrome等主流浏览器识别恶意网站主要是通过黑名单功能,使用EV SSL证书(Extended Validation SSL Certificate)也可以有效的识别钓鱼网站,该证书在地址栏上会以已绿色显示 例如https://www.alipay.com/<script><img><iframe><link>标签都是可以跨域家在资源,不受同源策略的限制。这些带‘src’属性的标签每次加载的时候,实际上是由浏览器发送了一次GET请求。不同于XMLHttpRequest的是,通过src属性加载的资源,浏览器限制了Javascript的权限,使其不能读、写返回的内容。但是XMLHttpRequest受到同源策略的约束,不能跨域访问资源。但是W3C制定了XMLHttpRequest跨域访问标准.浏览器对于安全方面的努力 IE8退出了XSS Filter功能,当用户访问的URL中包含了XSS攻击脚本时,IE就会修改其中的关键字符使得攻击无法完成,并对用户弹出提示 浏览器插件的开发,带来了新的安全隐患,同时也带来了新的挑战。
跨站脚本攻击(XSS) Cross Site Script, to clarified from CSS, it's named XSS XSS Payload: 1、构造get, post请求: <img>的src属性 构建form表单 使用XMLHttpRequest 2、XSS钓鱼:使用xss模仿出一个一模一样的登陆框,将用户输入直接提交至hacker的server,这个可以去处理验证码的问题 3、识别用户浏览器: 可以通过alert(navigator.userAgent),但是userAgent可以伪造,可以采用其他代码来实现,见page 55 4、识别用户安装的软件: 查找插件:navigator.plugins 5、CSS history hack:通过css发现用户曾经访问过的网站 http://ha.ckers.org/weird/CSS-history-hack.html 可以访问到你曾经访问过的哪些历史记录,FF已经在2010.3决定修补这个问题,但是该问题依然在chrome上存在 6、获取用户的真实IP:需要借助第三三方软件来完成 XSS 攻击平台:其目的为演示XSS的为好,以及方便渗透测试使用,没事可以去玩 Attack API: http://code.google.com/p/attackapi/ BeFF: http://bindshell.net/tools/beef.html XSS-Proxy:通过嵌套iframe的方式,实时的远程控制被XSS攻击的浏览器 XSS Worm:蠕虫一般多发于存储型XSS,并且交互行为多的页面。 1、Samy Worm:http://namb.la/popular/tech.html (留着以后看) 2、百度空间蠕虫:http://security.ctocio.com.cn/securitycomment/57/7792057.shtml (留着以后看) 调试 1、Firebug on FF;Inspect element on Chrome;Developer tools on IE 8 2、Fiddler:www.fiddler2.com/fiddler2/ 3、Http Watch:商业软件,目标网站是https会特别有用
XSS构造技巧 1、字符编码:需要熟悉Unicode 2、绕过长度限制: 利用location.hash, location.hash则可以用来获取或设置页面的标签值。比如http://ued.alimama.com#admin的location.hash=”#admin”,利用这个属性值可以实现很多效果。 refer to http://www.jz123.cn/text/0718524.html利用注释附绕过长度限制: 3、使用<base>标签mark 4、window.name的妙用<base>可以出现在页面的任何地方,并作用于该标签在之后的所有标签;<base>标签只用于<head>标签之内,这个说法是不对的steps 1. 在目标窗口,给window.name赋值,此处可以附上cookie等敏感数据 2. 当前窗口跳转至另一个url,可以通过window.name获取到参数,因为window对象是当前窗口 5、以往的一些XSS Apache Expect Header XSS, Anetha:利用反射xss和存储xss协作攻击 Flash XSS : allowScriptAccess, allowNetworking 参数的配置很重要 refer to https://www.owasp.org/index.php/Category:SWFIntruder https://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project JS框架的安全问题: Dojo 1.4.1, YUI也遭遇过Dojo相同的问题对当前窗口的window.name对象赋值,没有特殊字符的限制,因为window对象是浏览器的窗体,而并非document对象,因此很多时候window对象不收同源策略的限制,攻击者可以利用这个对象,实现跨域、跨页面传递数据。
XSS的防御
1、HttpOnly
httpOnly标签至今已经逐渐成为一个标准,浏览器禁止JS访问带有HttpOnly的Cookie,HttpOnly可以选择性的加载任何一个Cookie值上
- Java EE
- response.setHeader("Set-Cookie","cookiename=value; Path=/;Domain=domainvalue;Max-Age=seconds;HTTPOnly");
- C#
- HttpCookie cookie = new HttpCookie("myCookie");
- cookie.HttpOnly = true;
- Response.AppendCookie(cookie);
- PHP 4
- header("Set-Cookie: hidden=value; httpOnly");
-
- PHP 5
- setcookie("cookiename","value",NULL,NULL,NULL,NULL,TRUE)
2、输入检查
如果遇到富文本的输入,实现起来比较困难,因为过滤之前需要考虑到语境
3、输出检查
a.安全的编码函数:
输出对象为html时,采用HtmlEncode,HtmlEncode不是专用名词,他只是一种函数实现。他的作用是将字符转换成HTMLEntities,对应的标准是ISO-8859-1
至少需要转换以下字符:
& --> &
< --><
> --> >
" --> "
' --> '
/ --> /
JS编码方式可以使用JavascriptEncode,
refer to https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
采用框架并不一定能够全部解决问题,比如说Phthon的web2py,但需要在正确的地方使用正确的编码方式。
正确的防御XSS
在HTML标签中输出、在HTML属性中输出:对变量使用HtmlEncode
在<script>标签中输出、在事件中输出:使用JavascriptEncode
在CSS中输出:推荐使用OWASP ESAPI中的encodeCSS()方法
String safe = ESAPI.encoder().encodeForCSS(request.getParameter("input"));
在地址中输出:OWASP ESAPI中的encodeForURL()方法(此API并没有解决伪协议的问题),先检查变量是否以“http”开头(如果不是则自动添加),以保证不会出现伪协议类的XSS
String safe = ESAPI.encoder().encodeForCSS(request.getParameter("input"));
处理富文本:采用XSS filter
For Java: Anti-Samy refer to https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project
For PHP: http://htmlpurifier.org/
防御DOM Based XSS:复合的XSS防御
从$var输出到<script>的时候需要做JavascriptEncode,在输出到html的时候,如果是输出到事件或者脚本,再做一次JavascriptEncode,如果输出到html,做HtmlEncode,即,输出点即为防御点。
cheatsheet for DOM Based XSS:http://code.google.com/p/domxsswiki/
理论上,XSS漏洞数量很多,并且可能复杂,但是确实可以彻底解决的。
CSRF( Cross Site Request Forgery) 浏览器的cookie有两种:不同浏览器对于cookie的管理策略是不同的 a.session cookie(临时cookie):对于server来说是session b.third-party cookie(本地cookie):对于server来说是cookie P3P header:W3C指定的一项关于隐私的标准:The Platform for Privacy Preferences.refer to http://www.w3.org/TR/P3P/ CSRF的防御: a. 验证码 b. Referrer check:最常用的就是防止图片盗链,但该方法用来监控比较好 c. Token:使用 Anti CSRF Token,token在用户提交表单前都有效,在提交之后失效,并且重新生成一个新的token,token可以放在用户session或者cookie里,不宜放在url上 在防御CSRF之前,必须防止XSS,否则CSRF将无法被防御。如果网站返回给浏览器的HTTP头中包含了P3P头,某种程度上说,是允许浏览器发送第三方cookie,并且对于cookie的影响将扩大到整个域中的所有页面,因为cookie是以域和path为单位的。P3P头的介入会改变网站的隐私策略,将不再拦截浏览器发送第三方cookie,并且只设置一次即可。 很多时候,如果测试CSRF时发现<iframe>等标签在IE能发送cookie,很有可能是P3P的原因(因为IE默认会拦截iframe发送cookie)
视觉上的欺骗手段,将一个透明的、不可见的iframe覆盖在一个网页上,然后诱使用户在该网页上进行操作,此时用户将在不知情的情况下点击透明的iframe页面。通过调整iframe页面的位置,可以诱使用户恰好点击在iframe页面的一些功能性按钮上。 对于当前的web浏览器来说,主要用在钓鱼、欺诈和广告作弊等方便,并且实施成本高,个人认为影响并不算大 拖拽劫持&数据窃取: page 131 触屏劫持:TapJacking,运用于手机客户端,相当有威力,因为在手机客户端很多浏览器为了节约空间,会隐藏地址栏,并且可以不只是用在浏览器上哦,手机屏幕都是可以被劫持的对象 防御方式: 1. frame busting:采用js禁止使用iframe的嵌套,但是容易被绕过 refer to http://seclab.stanford.edu/websec/framebusting/framebust.pdf 2. X-Frame-Options: 比较优选的方案就是使用http头:X-Frame-Options, 支持的浏览器有:IE 8+; Opera 10.50+; Safari 4+; Chrome 4.1.249.1042+ FF 3.6.9 有3个可选值: DENNY: 浏览器会拒绝当前页面加载任何frame页面 SAMEORIGIN: frame页面的地址只能为同源域名下的页面 ALLOW-FROM origin: 可以定义允许frame加载的页面地址
新标签引起的XSS:如果过滤是采用黑名单过滤,那么新标签的引用有可能带来新的xss攻击,例如<video><audio>标签
refer to http://code.google.com/p/html5security/
<iframe>的sandbox属性:可以控制同源访问、访问顶层窗口、提交表单、执行脚本的事件
<a>和<area>的ref属性:<a href="xxx" rel="noreferrer" /> 指定noreferrer后,浏览器在请求该标签置顶的地址时将不再发送referrer
<canvas>:HTML的一大特性,超越了<img>,可以让JS在页面中直接操作图片对象
refer to http://diveintohtml5.info/canvas.html
通过canvas自动识别Megaupload提供的验证码: http://userscripts.org/scripts/review/38736
Cross-Origin Resource Sharing:根据跨域访问提出的新标准,在request的header中增加Origin,即本域;可以在response中看到Access-Control-Allow-Oringin,此属性中如果含有当前发送请求的域,则发送请求的域可访问被请求域的资源
postMessage--跨窗口传递消息
postMessage 允许每一个window (包括当前窗口, 弹出窗口, iframe)对象往其他的窗口发送文本消息,从而实现跨窗口的消息传递。这个功能不收同源限制
使用postMessage的时候有2个安全问题需要注意:1、在接收窗口验证domain,即做同源策略的验证;2、需要对发送的请求的信息进行安全检查,例如防止注入
Web Storage:W3C的新标准,分为Session Storage和Local Storage,受到同源策略的约束,安全的隐患存在于将恶意代码或者敏感信息保存在Web Storage中
js的使用方法:
- Setter: window.sessionStorage.setItem(key, value);
- Getter: window..sessionStorage.getItem(key);
Blind Injection:
在服务器没有返回错误会先时完成的注入攻击,手法可使用 and 1=1, and 1=2等,提交之后根据返回的结果可以判断是否有SQL injection.
Timing Attack: 利用BENCHMARK()函数,让同一个函数执行若干次,使得结果返回的时间比平时要长;通过时间长短的变化,可以判断注入是否成功
攻击工具:sqlmap.py refer to http://sqlmap.sourceforge.net/
常见攻击技巧:
盲注
利用UDF( User defined functions) :此攻击的用户是有很高权限的用户,可以通过UDF或者sql语句执行当前OS命令
攻击存储过程:存储过程本生没有输入检查,很致命
利用字符集编码攻击:这个比较麻烦,解决的方案是统一DB, OS,Web Server所使用的字符集,建议使用UTF-8,如果无法统一,则需要单独实现用于过滤或者转移的安全函数
利用Sql column truncation攻击:
Mysql有一个配置选项,sql_model的属性"STRICT_TRANS_TABLES"如果被设置,在插入表的时候如果有字段超长,则会自动截断并且发出warning,而不是error,这样会导致程序与数据的初衷不符合,可能会出现问题,例如db中有用户叫做admin,且column长度限制为5,攻击者申请新用户叫做admindaad980eqdads098dadan0,很容易会跳过程序的检查,并且在插入时自动截取前5个字符,admin,攻击成功
防御:使用黑名单,很容易被跳过
1、针对sql最佳方式就是使用预编译:
java--> PreparedStatement()
.NET--> SqlCommand(), OleDbCommand()
PHP--> bindParam()
Hibernate --> bind parameter
SQLite--> sqlite3_prepare()
2、避免使用procedure,如果必须需要使用,则使用安全的procedure:
java-->
- CallableStatement cs = connection.prepareCall("{call prc_name(?)}");
- cs.setString(1,"xxx");
3、使用安全的函数
可以参考OWASP ESAPI中的实现- Codec orac = new OracleCodec();
- String query = " select 1 from t_user where username ='"+ESAPI.encoder().encodeForSQL(orac, username)+"' and password ='"+ESAPI.encoder().encodeForSQL(orac, password)+"'";
4、从DB自身的角度来看,使用最小权限原则,不应该有操作文件或者定义函数等功能,并且应该和Web服务器分离
附------------------------------------------------------
Mysql中的一些函数- --将expr执行count次的耗时,常用语性能调试的语句
- BENCHMARK(count, expr):
- select BENCHMARK(5000000, curdate());
-
- --查看数据库版本
- select @@version from dual;
-
- --将查出的语句写入到文件中
- SELECT table_name, table_type, ENGINE
- FROM information_schema.TABLES
- WHERE table_schema ='mysql'
- ORDER BY table_name DESC into outfile 'path';
-
- --将敏感数据读出,通过INTO DUMPFILE将该文件写入到系统中,然后通过LOAD DATA INFILE将文件导入创建的表中,通常被用于导出一个WebShell,为攻击者的进一步攻击做铺垫,因为普通的DB user一般不具备操作文件的权限
- create table t_testAtt(line BLOB);
- select load_file('sensitiveFile') INTO DUMPFILE ('targetPath');
- LOAD DATA INFILE 'targetPath' INTO TABLE t_testAtt;
-
XML注入
代码注入:多见于脚本语言,但是服务端语言也有可能被注入
Java如果使用了脚本引擎,就可能发生注入
- import javax.script.*;
-
- // para="hello');var fImport= new JavaImporter)(java.io.File); with (fImport){ var f = new File('new'); f.createNewFile();}";
-
- public void test(String para) throws Exception{
- ScritpEngineManager manager = new ScriptEngineManager();
- ScriptEngine engine manager.getEngineByName("JavaScript");
- System.out.println(para);
- engine.eval("print('"+para+"')");
- }
CRLF注入:CR--> Carriage Return( ASCII 13, \r, 0x0d); LF--> Line Feed( ASCII 10, \n, 0x0a)
对http头的影响比较明显,如果请求中包含了/r/n,并且该请求会被放入到cookie中,则返回的头,则会多出一个/r/n,连续2次换行意味着http头的结束,在此空间内可以执行攻击,从此处也可以发现,注入http头的印象很大。
文件上传导致的危害:绕过文件上传检查功能:1、上传的文件是WebShell,服务器的Web容器解析并且执行了用户上传的文件,导致代码执行。完成攻击的条件:a.上传的文件能够被web容器解释执行; b.用户能够从Web上访问到这个文件; c. 上传的文件没有被格式化、安全检查、压缩等而导致改变功能。 2、上传文件是类似于Flash的策略文件crossdomain.xm,黑客可以控制该域下的行为。 3、上传文件是木马、病毒,黑客用来有道用户或者管理员下载的 4、上传文件是钓鱼图片或者包含脚本的图片,被用于钓鱼或者欺诈防御: 1、文件服务器和Web服务器分离,并且单独设置文件服务器的域名,可以通过同源策略的关系使客户端攻击失效。 2、文件上传的目录设置为不可执行 3、检验文件类型,结合使用MIME type、后缀检查,黑名单靠不住,使用白名单;对于图片的处理,可以使用压缩函数或者resize函数,在处理图片的同事破换图片中可能包含的HTML代码。 4、使用随机数改写文件名和路径攻击者手动修改了上传过程中的POST包,在文件名后添加一个%00字节,则可以阶段某些函数对文件名的判断,比如说在C、php等语言的常用字符串处理函数中,0x00被认为是终止符。例如应用原本只允许上传JPF图片,可以构造文件名(需要修改POST包)为xxx.php[\0].jpg,由于[\0]为十六进制的0x00字符,.jpg就绕过了应用上传文件类型的判断;并且对于服务器来说,此文件因为0字节阶段的关系,最终会变成xxx.php
Authentication & Authorization. 认证与授权 密码必须以不可逆的加密算法,或者是单项散列函数算法,加密后存储在DB中,一般采用的加密方式是需要加上salt 可采用多因素认证来增加认证强度,例如支付宝中的各种认证方式 需要预防Session劫持,这个和SessionID的管理有关,个人认为只要控制了xss,就不会出现session劫持的情况。 SSO:最开放和流行的SSO系统是OpenID
RBAC(Role-Based Access Control):基于角色的访问控制 基于URL的访问控制,基于方法的访问控制:Spring Security是框架实现了Filter Chain,但是缺乏一个管理界面供灵活配置,因此每次调整权限时,需要重新修改配置文件或代码,学习成本较高,维护成本也较高 例子: http://www.wooyun.org/bugs/wooyun-2010-0788 http://www.wooyun.org/bugs/wooyun-2010-01429 http://www.wooyun.org/bugs/wooyun-2010-01352 不要把后台管理页面藏起来,虽然搜索引擎的爬虫搜索不到这些页面,但是攻击者管用的几辆是使用一部包含了很多后台路径的字典把“藏起来”的页面扫出来。 水平权限管理:基于数据的访问控制,这个问题很常见 OAuth: 从OpenID中分离出来,解决了交互的信任问题
Stream Cipher Attack: 流加密法是基于异或(XOR)操作进行的,每次都只操作一个字节,但是性能非常好,常见的加密算法有RC4, ORYX, SEAL WEP破解:page 233 分组加密法: 有通用的几种加密模式:ECB, CBC, CFB, OFB, CTR 常见的分组加密算法有DES, 3-DES, Blowfish, IDEA, AES EBC模式(Electronic Codebook, 电码薄)现实中,最著名的针对流密码攻击可能就是WEP密钥的破解。WEP是一种常用无线加密传输协议,破击了WEP的密钥,就可以以此密钥连接无线的Access Point,WEP采用RC4算法
防御XSS, 采用模板引擎可以统一控制 1. 在HTML标签中输出变量 2. 在HTML属性中输出变量 3. 在Script标签中输出变量 4. 在事件中输出变量 5. 在CSS中输出变量 6. 在URL中输出变量 防御CSRF: 跟业务挂钩比较重,一般在“增、删、改”操作的时候需要防御,“读”并不需要 1. token 2. “增、删、改”操作时需要采用post,不能使用get 关于Ajax的例子可见page 286 Header管理:主要是需要对抗CRLF注入,将value编码所有的\r\n即可。 管理好跳转的页面,采用白名单,设置HttpOnly
DDOS ( Distributed Denial of Service)分布式拒绝服务 CC攻击( Challenge Collapsar):对资源消耗大的应用页面不断发起正常的请求,以达到小号服务器资源的目的。 防御方案: 1. 针对每个“客户端”做请求频率限制page 298 2. 代码要做好性能优化 3. 网络架构需要做优化 Slowloris攻击:原理是以极低的速度往服务器发送http请求,使Web Server的所有连接都被恶意链接占用, page 307, 该攻击对很多Web Server都是有效的,当然很多Web Server可以通过配置参数来解决这个问题 HTTP Post DDOS:类似于Slowloris, 在发送Http post包时,指定一个非常大的Content-Length值,然后以很低的速度发送,以保持连接不断开 Server Limit DOS:Web Server的Http长度都是有限制的,request header与request body. 攻击者可以在利用xss在Cookie里面写入超长的信息,超过header的限制,服务器则会返回4xx错误,防御方式可以修改Server参数 ReDOS:正则表达式DOS,是代码的缺陷,和以上攻击以略有占用资源不同,有的正则写得有缺陷的话,会导致运算时间加长,这个影响看来是挺大的 通用的防御: CAPTCHA( Completely Automated Public Turing Test to Computer and Humans Apart, 全自动区分计算机和人类的图灵测试),/**好拗口 */ 现在常用方式为验证码,但是并不是最优的solution,Yahoo( Detecting system abuse) 提出了更宽广的思路
直接跳过了.以后接触到php的时候再回来读 简单来说,因为灵活,所以导致了PHP代码安全评估的难度较高,常见漏洞有:文件包含漏洞、代码执行漏洞
Apache Httpd: 1. 检查Module的安装情况,根据“最小权限原则”,应该尽可能的减少不必要的Module,对于要使用的Module,检查起对应版本是否存在安全漏洞 2. 需要为Apache Httpd建立单独的一个user/group,该user/group的唯一作用就是运行Apache Httpd,不能具备shell 3. 保护好Apache log,比如实时的发送到远程的syslog服务器上 Nginx: 同Httpd的第2点,http://nginx.org/en/security_advisories.html 官方已经列出了安全的隐患和漏洞,需要保持Nginx升级更新 jBoss 默认安装时,访问JMX-Console (http://address:port/jmx-console )是没有认证的 需要删除JMX-Console的,移除jmx-console.war和web-console.war即可 Tomcat Tomcat Manager部署war包所需的manager权限应该单独配置给一个账号,不要使用默认的tomcat账号 tomcat-users.xml HTTP Parameter Pollution 通过向服务器发送GET或者POST请求时,提交两个相同的参数,不同服务器的选择会有不同,可能会绕过安全检查,关于服务器的处理方式,参见page 364
Secure at the Source,以最小的成本提高产品的安全性 关于SDL,我们可以基于Microsoft或者OWASP的帮助,例如Microsoft的STRIDE模型,OWASP的SAMM( Software Assurance Maturity Model https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model) 针对于敏捷开发,SDL有着不同的实现方式,但是有一下准则: 1. 与Project Manager充分沟通,排出足够的时间,否则裸奔是很危险的 2. 规范公司的立项流程,确保所有项目都能通知到安全团队 3. 树立安全部门的权威,项目必须由安全部门审核完成后才能发布 4. 将技术方案写入开发、测试的工作手册中 5. 培训 6. 记录所有的安全BUG,产生需要有report,并且能够让程序员活跃起来交流 需求:check list: from page 410 to 414 开发阶段 1. 采用安全的组件 (OWASP ESAPI: https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API) 2. 指定安全的开发规范,并且将安全的开发规范写入文档中,让安全方案落地 审计:核心思想并非直接检查代码是否安全,而是检查开发者是否遵守了开发规范 审计工具: commercial: IBM Rational Appscan, WebInspect, Acunetix WVS free: w3af, skipfish( http://code.google.com/p/skipfish/ , 二次开发的上佳选择)
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。