首页 > PHP, 架构 > Web安全威胁与防范工作总结

Web安全威胁与防范工作总结

WEB开发中由于项目规模和需求的规范性,安全问题可能并不是所有的时候都能引起足够的关注,大多数时候技术人员根据经验和习惯作一些处理,一些相对比较严格和苛刻的问题,往往都是出现问题以后才临时解决。小规模应用出现状况的情况比较少,而且处理起来也可以比较迅速,但是应用达到一定规模以后,如果前期没有做好足够的工课,后期补漏洞的代价就比较高了。所以在条件允许的情况下,把安全问题放在首要位置,或许是一个比较明智的选择。下面是本人总结的几点WEB安全相关知识,备以常参。希望对大家熟悉WEB攻击原理与处理,提高高质量代码产出率和娴熟应对安全威胁有所帮助,

  • Cookie SQL注入
    基本上给用户提供“输入”的入口都会给注入留下机会,Cookie也不例外。 如果应用程序对访问的输入处理未做检查或者检查的不完善,访问都便可以构造恶意数据,当数据并入SQL查询中时,就有可能暴露敏感数据。

    /* 实例代码 */
    $id = $_COOKIE[‘id’];
    $sql = “SELECT id,login FROM users WHERE id=$id”;
    $result = mysql_db_query($mysql_database, $sql,$conn);
    $row = mysql_fetch_row($result);

    上述代码中变量$id,接受COOKIE方式传递的数据,并未对危险字符做过滤,假
    如客户端提交“-999 UNION SELECT users(),version()”,将会输出Mysql的用
    户名以及数据库版本。
    通常客户端提交方式包含GET、POST、COOKIE、User-Agent、Referer、Accept-Language等. 

  • Mhtml协议跨站脚本攻击
    在IE中,当嵌入资源的URL的协议为MHTML时,IE将调用MHTML Protocol Handler,把该资源当作MHTML格式文件解析处理。MHTML Protocol Handler解析MHTML格式文件,其结果交给IE渲染,MHTML Protocol Handler根据Content-Location值找到对应的数据块,再根据Content-Transfer-Encoding值对一下这段base64数据解码,如果base64数据中包含精心构造的跨站脚本代码,那就会被执行。下边PHP代码为例,做简要的分析。

    /* 实例代码 */
    $str = $_GET[‘name’];
    echo $str;

    上述代码中变量$str,接受GET方式传递的数据,并未对危险字符做过滤,假如客户端提交“x\\nContent-Type:multipart/related;boundary=x\\nContent-Location:x\\nContent-Transfer-Encoding:base64\\r\\n\\r\\nPHNjcmlwdD5hbGVydCgxKTs8L3NjcmlwdD4=–\\n!x”,其中“PHNjcmlwdD5hbGVydCgxKTs8L3NjcmlwdD4=”是<script>alert(1);</script>字符串的base64编码形式。那么alert函数将在浏览器内执行。
    Mhtml协议跨站脚本攻击主要危害包括:
    [1]获取其他用户Cookie中的敏感数据。
    [2]屏蔽页面特定信息。
    [3]伪造页面信息。
    [4]拒绝服务攻击。
    [5]突破外网内网不同安全设置。
    [6]与其它漏洞结合,修改系统设置,查看系统文件,执行系统命令等。

  • 跨站脚本攻击(XSS)
    XSS又叫CSS  (Cross Site Script) ,跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意html代码,当用户浏览该页之时,嵌入其中Web里面的html代码会被执行,恶意代码会被执行或者通过给管理员发信息的方式诱使管理员浏览,从而获得管理员权限达到恶意用户的特殊目的。XSS属于被动式的攻击,因为其被动且不好利用,所以许多人常呼略其危害性。

    示例代码:
    http://www.yes.com/shlm/?app=shop&keyword=1parameter: keyword=1, xss: */–>'”></iframe></script>/style></title></textarea><script>alert(/Webscan5/)</script>

  • 宽字符集跨站脚本
    在GBK字符集中,0xbf27不作为多字节字符,而0xbf5c是多字节字符。当注入字
    符比如0xbf27时,因为0x27为’,所以php语言中addslashes()在27前加
    上5c,把0xbf27修改为0xbf5c27。而0xbf5c27的0xbf5c被认为时一个多字节字
    符,所以后面的0x27就有可能闭合前边代码中的单引号,当然与单引号机制相
    同的还有双引号,这样就为未闭合跨站脚本的代码提供了可能。下边PHP代码为
    例,做简要的分析。

    /* 实例代码 */
    parameter: keyword=1, xss: */–>%cf”%d5′></iframe></script></style></title></textarea><script>alert(/Webscan5/)</script> 

    <?php
    $str = $_GET[‘name’];
    echo ‘”‘.addslashes($a).'”‘;
    ?>

    上述代码中变量$str,接受GET方式传递的数据,假如客户端提交“%cf\”%d5′<script>alert(1)</script>”,那么就闭合代码中$str变量前边的单引号、双引号,alert函数将在浏览器内执行。

    主要危害包括:
    [1]获取其他用户Cookie中的敏感数据。
    [2]屏蔽页面特定信息。
    [3]伪造页面信息。
    [4]拒绝服务攻击。
    [5]突破外网内网不同安全设置。
    [6]与其它漏洞结合,修改系统设置,查看系统文件,执行系统命令等。

  • 跨站请求伪造(CSRF)
    CSRF(Cross-site request forgery),中文名称:跨站请求伪造,也被称为:one click attack/session riding,缩写为:CSRF/XSRF。
    你这可以这么理解CSRF攻击:攻击者盗用了你的身份,以你的名义发送恶意请求。CSRF能够做的事情包括:以你名义发送邮件,发消息,盗取你的账号,甚至于购买商品,虚拟货币转账……造成的问题包括:个人隐私泄露以及财产安全。
    从上图可以看出,要完成一次CSRF攻击,受害者必须依次完成两个步骤:1.登录受信任网站A,并在本地生成Cookie。2.在不登出A的情况下,访问危险网站B。看到这里,你也许会说:“如果我不满足以上两个条件中的一个,我就不会受到CSRF的攻击”。是的,确实如此,但你不能保证以下情况不会发生:1.你不能保证你登录了一个网站后,不再打开一个tab页面并访问另外的网站。

    2.你不能保证你关闭浏览器了后,你本地的Cookie立刻过期,你上次的会话已经结束。(事实上,关闭浏览器不能结束一个会话,但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了……)

    3.上图中所谓的攻击网站,可能是一个存在其他漏洞的可信任的经常被人访问的网站。

    上面大概地讲了一下CSRF攻击的思想,下面我将用几个例子详细说说具体的CSRF攻击,这里我以一个银行转账的操作作为例子(仅仅是例子,真实的银行网站没这么傻:>)

    示例:

    银行网站A,它以GET请求来完成银行转账的操作,如:http://www.mybank.com/Transfer.php?toBankId=11&money=1000

    危险网站B,它里面有一段HTML的代码如下:

     <img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

    首先,你登录了银行网站A,然后访问危险网站B,噢,这时你会发现你的银行账户少了1000块…

    为什么会这样呢?原因是银行网站A违反了HTTP规范,使用GET请求更新资源。在访问危险网站B的之前,你已经登录了银行网站A,而B中的<img>以GET的方式请求第三方资源(这里的第三方就是指银行网站了,原本这是一个合法的请求,但这里被不法分子利用了),所以你的浏览器会带上你的银行网站A的Cookie发出Get请求,去获取资源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”,结果银行网站服务器收到请求后,认为这是一个更新资源操作(转账操作),所以就立刻进行转账操作……

WEB安全防御和自检几点建议

  1. 使用参数化的过滤性语句
    要防御SQL注入,用户的输入就绝对不能直接被嵌入到SQL语句中。恰恰相反,用户的输入必须进行过滤,或者使用参数化的语句。参数化的语句使用参数而不是将用户输入嵌入到语句中。在多数情况中,SQL语句就得以修正。然后,用户输入就被限于一个参数。
  2. 生产环境避免暴露错误消息
    生产环境应该避免暴露错误消息显示,尤其是SQL祥细错误信息
  3. 使用专业的漏洞扫描工具
    像Code Review一样,用工具扫描一下应用可以避免大部分常规性漏洞。一个完善的漏洞扫描程序不同于网络扫描程序,它专门查找网站上的SQL注入式漏洞。技术人员的知识更新落后于最新攻击技术是很正常的, 利用最新的漏洞扫描程序可以查找最新发现的漏洞。
  4. 开发过程中所有阶段实施代码安全检查
    在部署Web应用之前实施安全测试,这种措施的意义比以前更大、更深远。团队还应当在部署之后用漏洞扫描工具和站点监视工具对网站进行测试。

当然,这是很理想状态了,就像文章开头所说的那样,大多数时候,由于规模、需求和项目进度问题,一些安全问题可能并不是所有时候都会被那么重视,所以增强安全意识,提高高质量代码产出率或许是最有效,也是最可行的方案了。SO,要想项目上线后,不至于出现因为安全问题而被什么什么的尴尬,还是先练练内功吧 🙂

另外分享一段安全过滤代码,经过生产环境测试和多款安全扫描工具扫描,能解决大部分常见安全问题,仅供学习参考。猛击这里:)

–EOF–

引用资料:

  1.  http://blog.jobbole.com/23911/
  2. http://bbs.ctocio.com.cn/thread-7837688-1-1.html
  3. http://security.ctocio.com.cn/websec2009/
  4. IE下MHTML协议带来的跨域危害
  5. 分享一段预防SQL注入和跨站攻击代码
分类: PHP, 架构 标签: , , , ,
  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.

=2加4(必填)请输入两数相加的结果。