【IT168 资讯】以“互联网安全新思维”为主题的OWASP2011亚洲峰会在11月8日-9日成功举办。本届大会以“网络安全产品测评”、“OWASP应用安全技术”“业务安全发展新思路”“云安全”等多个角度展开深入的讨论。会上，思科SCG安全团队核心成员夏玉明先生为我们分享《web 2.0安全代码》。

▲思科SCG安全团队核心成员夏玉明演讲

　　夏玉明首先介绍说：“我们团队主要负责产品安全以及做安全审计，最后我们也会用一些工具和流程保证产品的安全。今天和大家讨论的内容有以下几点：一是Web2.0和普通的Web应用有什么不同；二是工程技术人员最怕的用户存储控制的问题；三是Seession方面的管理；四是输出过滤；最后讨论下如果进行安全审计。”

　　Web2.0用户数量大，用户角色丰富，相互关系复杂，造成认证和授权的问题比较突出，Web2.0当中业内知名的是跨站问题，因为功能输入输出点比较多，我们开发在写代码的时候经常有所遗漏。同时Web2.0是人际交流网络，Web2.0主要讲应用性和人性化，如果用不好，容易造成信息泄漏的问题。这几个问题，我们以下都会说到。

　　在传统的门户网站，普通的Web网站里面，用户管理员负责发布各种信息，普通用户很少参与，到了Web2.0这种模式有所改变，验证和授权变成了基本需求。这是一个典型Web2.0网站，对不同用户显示不同界面，上面的界面显示给普通用户看的，下面页面显示给管理员看的。我们看看它的实现代码，如果它的代码像图上这样，大家看有没有安全问题?在用户控制方面，这里有两个安全隐患，首先，安全不是靠遮遮掩掩实现的，虽然它隐藏了界面，但是黑客或者其他人可以想办法看到账号管理的界面，黑客可以执行这段代码之前可以改掉它的代码，对普通用户显示它的代码，这就是安全隐患了。

　　我们不要依靠客户端的认证，大家看这里另外一个API，它的作用是删除，我们看它的代码有什么问题没有?大家看到这是JAVA代码，没有进行客户端认证，它没有我刚才讲的问题了。现在它还有什么其他问题?某个人在Web2.0当中，我们经常对某个人进行认证，证实他的身份是某个人，但是我们操作某件事的时候任何一个成功登录的用户可以删除别人的Blog，这就是安全问题。

　　这是一个界面添加用户的界面，点击左边的链接添加用户，这种实现的方式本身有什么问题没有?(如图)，大家看到以URL作为判断来源，这是不安全的做法，我们曾经做过一个项目中这种问题不差十个，新用户第一次登录先让他填写资料，第二步更换图象，我们这里会遇到的问题是别人利用URL非法更改资料和添加图象。所以我们不要依靠标识参数。我们一定要保护关键操作，不管新用户或者银行转帐一定要防御CSRF的方式。然后如果Ticket用了用户名加了securekey来执行，这里有什么问题?它没有防止攻击，网站管理员曾经看到过链接，他记下来可以继续使用，这个设计没有考虑到重放攻击，防止办法可以是增加一个值或者时间戳，每次值不一样，不能随便添加用户。要防止重放攻击。

　　经常用户登录的时候，都会记得把session重新附一个新的session，在用户重新登录时忘了把旧的session去掉。这是去年9月份的事件，首先大家登录自己的支付宝，当然在9月4号修复，大家登陆支付宝会看到自己的消费记录，你在多窗口浏览器在这里输入你想要登陆别人账号的密码，这个时候肯定是密码不对，回报错，输入五次会出现这种界面，密码错误多了，让你重新登陆，你这个时候会发现你以别人的身份进去了，我们开发过程中会不小心造成的错误，而且对开发来说不是很有意识的时候造成的错误。Cookie是服务器上一个值，放在机器浏览器上一个临时目录上面，我们对这个值进行保护，但怎么保护呢?那就是密钥不被重新传到本地，密钥始终在本地服务器上才能保证安全。我们这边的正确做法是满足用户需求的条件下，我们设最短时限，比如说常用的cookie以两周为限，超过两周就无效了。关于域名和路径大家经常会忽视，假如谷歌有两个站点，那么正常写cookie的时候就应该写两个路径，否则写一个路径就比较危险。

　　输入和输出的过滤，与XSS相关，但为什么把输出过滤单独提出来讲了，因为90%以上的XSS问题都与输出没有做或者输出没有做正确有关。在任何可以看得见的页面当中，所有来源用户的输入的输出都得进行编码，在所有的页面现实中包括用户看得见，包括用户点开展开看见的，来源所有用户输入的输出，它可以是直接输入，也可以间接输出，可以刚刚输出也可以一个月前输入的。对于不常见的页面看不见的输出或者输入，我们要做相应的编码，比如用户输入十次会有十次输出，如何在每个名字进行编码，大家可以进行代码扫描，一个项目里面，统一往页面输入函数的名称，用代码扫描名字，然后进行跟踪。最好的方式像我们做的每天都进行扫描，每天发报告，代码里发现问题以后立马进行修改。有的代码被扫描到了被误解，你是用户输出的也没错，但是它是电话号码，纯数字有什么安全问题?大家都设想它是一个数字不会造成安全问题。我们没有在某些地方检验是不是数字，或者只靠GM代码检查它，即使它是数字也要进行编码之后再输出。

　　数据安全，大家知道钓鱼排名第四，钓鱼大家说是网站账号被盗，专业角度来说，钓鱼相当于机器浏览器上执行任意代码。防止钓鱼的情况下，有两个做法，首先进行URL限制，我们进行名单过滤。另外实际的正确做法监测用户账户活动，自动的发送警告邮件。两个账户同时在北京和上海登录，做的事情完全不同，就得警告邮件。很多账号做同一件事情，你就要考虑你的站点受到了钓鱼攻击。还要进行HTTPS进行验证，在比较高的条件下，所有的链接都要走HTTPS，我们尽量不要有HTTP的链接。至少要下面三点一定要走HTTPS，Verify CN、Verify date validity，CRL query。对于一个用户来说记很多密码记得不是很清楚，在我们站点上的密码说不定跟他的银行账号的密码一样，他的密码在我们数据库里面必须加密保存。密钥数据管理员一定知道，更进一步的安全不保存用户密码，保存用户密码计算过的值，比如哈希值，用户登录前取他输入的密码的哈希值进行校验。比如六位数字有一百万种可能，有一百万种哈希值，通过计算也很快算出来，我们这里推荐要加salt，168个bit的salt，有六个计算机也很难解开。

　　在Web2.0当中还有一些不经意信息泄漏。

　　Post method，比如说添加用户的信息，有信息泄漏的风险，浏览器不安全，网管也能看到，会看到某人访问了某些链接，某些URL在他看来就是密码。

　　HTTP Trace，我们肯定要关闭。

　　用户登陆失败的情况下，要提供统一的消息，不告诉大家，不告诉黑客，你是用户名还是密码错了，我们就告诉你用户名或密码错了，好处他没有办法用工具把所有用户名列出来。

　　我们用户隐私信息一定要保护，在没有明确用户授权的条件下，不能保护用户隐私信息，不管服务端还是客户端，用户信息是不允许非法收集的。

　　我们除了保护用户信息，还要保护我们自己。我们在显示一些信息给用户的时候，不要显示过于详细的信息。这是我前两天来之前看到大型网站所看的报错信息，作为友好型的信息，它的用户来说会看得一头雾水，但是对于黑客来说可以看的很清楚。

　　接下来分享一下其他常犯的错误，我们项目曾经开发过加密算法，我们用了两年时间，所有产品经理或者开发人员都认为它是安全，后来发现它并不安全，我们花了相当多的精力做了很多工作，我们改成AES算法。AES一定要用对。DES和MD5广泛使用的长度，我们现在都不推荐使用了，如果使用了，我建议你用工具扫描出来全部替换掉。随机数也是比较容易犯糊涂的地方，它的分布是随机的，但是值不是随机的，从前一个值可以推出后一个值，就有安全隐患，就不需要注册码之类的，需要保护的地方。最后是页面Charset，如果不指定的话，就会指定任意的，编码就会有安全问题。

　　相关链接：

　　OWASP2011演讲PPT下载专辑http://topic.it168.com/factory/owasp_2011/index.html
　　OWASP2011专题报道http://safe.it168.com/topic/2011/11-7/OWASP2011/index.html