web安全之整体观
在互联网的世界里面，自己家安全防卫没做到位，而受到损失的话，除非是国家银行，其他还真是自己得受着，没有任何挽回机会，甚至还会造成自己企业名誉和用户认知度的下降。
这篇就主要在整体上观摩一下web的安全问题，主要视角则是从从用户端到server的核心数据的路径上的安全环节问题的一些浅析。
首先我们看下web访问的请求路径图，如下：
那么我们将从webBrowser，firewall，webserver，appserver，及dbserver这几部分分别看些会有哪些安全隐患
（1）web browser
用户都是通过浏览器来访问我们的网站，而浏览器本身也是一个程序，如果程序在设计的时候，未考虑周全，当遇到异常情况，引发出不可预见的错误。如果这个漏洞，被不良用户利用，会造成信息泄漏，如黑客攻击网站，导致的后果是不堪设想。这方面主要是提醒用户及时更新浏览器的新版本。
(2)Firewall
这个阶段一般公司都会采用运维维护和专人负责的形式负责这块。当然这里会延伸出黑红客角色，但是作为开发者尚且是不太用关注这里的，术业有专攻，防火墙是一个web应用的安全防盾，交给专业的黑红客相关负责人员研究，感兴趣的话也可单独研究防火墙的安全技术
（3)webserver
这个关口主要是从以下几个方面看安全问题：
更新服务器版本----更新server的新版本，保证应用的母体是安全的
安全配置----保证root用户的权限不能开放到网络应用中，角色和权限设置要清晰明确，容不得半点差错，否则就是养虎为患了
比如：别人有可能会覆盖httpd可执行文件，那么下一次启动时，就会执行恶意代码。如果日志目录(对非root用户)是可写的，别人就有可能用一个指向其他敏感文件的连接来覆盖日志文件，使那个文件被改写为杂乱的数据。如果日志文件本身(对非root用户)是可写的，别人就可能伪造日志。这些所有的所有都会混乱试听，从而把应用的所有证据搞的一团糟。
观察日志文件----这个是个亡羊补牢的手段拉，是总结教训的地方，但是如果上一个环节上已经被伪造了日志的话，就悲剧了
CGI安全----Web Server一般都会调用CGI来响应用户的交互，而CGI对Web Server上的文件和目录是也有访问权限的，但是如果访问权限控制不合理，就可能导致安全隐患，举个例子来说：用户提交一个用户名到后台，后台CGI就把用户名对应的文件读出来，并显示到页面上
如果对用户名没有做过滤，用户提交了一个“http://www.cnblogs.com/http://www.cnblogs.com/http://www.cnblogs.com/etc/passwd”的用户名，那么服务器上的用户名信息就暴露给了hacker，可想而知这是多么地危险。这个阶段还有一些信息泄漏等安全问题。这个阶段也是开发者尤其需要关注的一个环节。我们开发的CGI一定要充分关注本身CGI的安全，并且不能相信该环节前面的环节的安全已经做到位，而要从自己这边一样重新安全防范一遍，bs两端都要做。
（4）appserver的安全
这里一般是涉及到用户登陆类的验证，要防止会话操纵和CSRF及并发攻击，这个是安全攻击常在的攻击面。包括ajax攻击，xml注入及sql inj等。这个阶段有个比较前端的手段，就是验证码。但是这个是远远不够的，对于足够有吸引力的app来说
（5）db的安全
这里大家都不陌生的，一个最最严重的问题就是sql inj，其次就是db的授权问题。
关于授权：应用程序永远不要使用数据库所有者或超级用户帐号来连接数据库，因为这些帐号可以执行任意的操作，比如说修改数据库结构（例如删除一个表）或者清空整个数据库的内容。应该为程序的每个方面创建不同的数据库帐号，并赋予对数据库对象的极有限的权限。仅分配给能完成其功能所需的权限，避免同一个用户可以完成另一个用户的事情。这样即使攻击者利用程序漏洞取得了数据库的访问权限，也最多只能做到和该程序一样的影响范围。我们经常可能不会意识到这一点，那是因为应用还没有做大，而hackers对你的app及db并没有太大的兴趣。
sql inj 相信大家已经很熟悉了，也是最起码的数据库应用会考虑到的一种安全问题，这里就不赘述了。
okay，上述大概就是整个web安全的一个整体观欢迎大家拍砖。
预告：
根据OWASP组织公布的2010年十大web安全漏洞，其中十大安全漏洞主要有：
1、注入漏洞(包括SQL/XPATH等)；
2、跨站脚本XSS；
3、认证攻击和会话操纵；
4、非安全对象直接引用；
5、跨站请求伪造；
6、部署安全；
7、非安全加密存储；
8、失败的网址访问缺陷限制；
9、不充足的传输层保护；
10、Jump跳转
后续会继续跟大家一起分享每个详细的安全问题的庐山真面目。
