【网站安全】网站通常面临的几种安全威胁及应对方式

【产生种种安全威胁的根源】

1、网站存储及传输机制的缺陷。

网站是wireless的，如何确定某个用户的信息，如何保存当前用户的信息便成为了一个亟待解决的问题。于是cookie及session解决了。

针对于某一个访问网站的用户，假如网站无法从cookie里面获取到他的sessionid（请注意：cookie是随着http请求发出去的，附在http协议的报头，所以，假如有人用窥探器的话，sessionid是无可遁形的），那么就生成一个session及分配一个sessionid给他（sessionid就放在cookie里面，jsp的是jsessionid，asp。net的是aspxsesssionid--类似）

然后用户获得该sessionid，以后每次访问网站都传送这个sessionid，服务器就可以识别这个用户了。最原始的网站对伪造sessionid的防御能力为0，

譬如，对于php而已，假如你用fgoole浏览器登录某个php网站后台，在用firefox里面的cookie修改插件，添加一个phpsessionid上去，然后用firefox直接访问php后台首页，你会发现成功登录。类似的方式有：javascript直接修改cookie的sessionid，用嗅探器直接截获http数据包。针对前一种javascript操作sessionid的解决方案可以将cookie的某个字段（譬如phpsessionid）设置为http-only，那么javascript就无法修改了。但是对于后面一个直接截获http明文协议数据的，基本属于协议缺陷，假如安全性要求高的话，可以用https安全传输，下文将尝试探讨如何修复这个明文传输的缺陷（要点：非对称加密解密传输密钥，对称加盟解密传输数据）---延伸，网络上面还有一种重放攻击，即是说，我截获了协议包，但是我不做任何修改，单纯将这个数据包重复发送，这种攻击很多网站也会中招（防范要点：时间戳），假如我不但劫持了这个数据包，而且修改了某些数据包再发送，那么应该如何防范（关键词：数据加密解密，数据签名）；但是扪心而问，我个人都认为，这种属于网站存储及传输机制的缺陷非常难以修复，因为这些缺陷或多或少需要用RSA,DES，数据签名，MD5等算法，甚至必须经过几次消息往返的确认，而对于浏览器而言，javascript有没有这种api都是问题（我可以负责任的告诉自己，这些api都可以用javascript实现，而且有人已经实现了，我就曾经使用了一个登录用服务端的公钥，再在客户端用RSA--javascript实现---算法加密数据，然后送到服务端再解密，但是效果不理想，尤其在ie6会卡死），至于其他的控制，网页都是页面级的，即登录有登录页面，列表有列表页面，不像客户端那样有一个统一的机制可以控制所有页面的数据传输（在传输前加密，在获取数据后解密），除非可以变成webqq那样的web os形式，但是，javascript的处理能力实在让人怀疑。吐槽了很多，因为我以前曾经就这种安全问题查了很多资料，结果最后自己都发现，要根除这种威胁，倒不如自己搞一个协议，加密解密数据签名时间戳等都堆上去（索性就用https，不用那么麻烦）。

2、html，javascript及浏览器解析机制的缺陷。

总所周知，html及javascript是解析型的脚本，即时解析，而非先编译，譬如说：

<%String str="<script>alert('ok');</script>";%><%=str%>

大家认为最后出现什么？

没错，最后会弹出一个alert窗口，里面的内容是“ok”，就是说，用户的输入可以被浏览器解析成为javascript脚本或者dom树，这种方式的威胁相对更容易解决。

通常只有几个地方需要注意：

1、图片的src，超链接的href，请注意，有些浏览器对这两个地方的八进制，16机制---x进制的字符串还原成一般字符串，上次在网上看到有人用

\xxx\xxx\xxx\xxx 这种格式的字符串来弹出窗口，一试，可怜的ie6还真中招了，所以，src，href出了英文字母里面，

:;'"{}[]<>,\|+_-)(*^$#@!~`

【为什么问候百分号及等号不需要过滤？因为有时候需要用到的地址格式为：xx.com/index.jsp?id=id1&id2=id2这种形式】
这些符号必须全部过滤，并且将白名单设置为普通英文及数字，中文，日文韩文（假如有其他需要支持的语言也可以设置），其他一切过滤，那么图片的src和超链接的href就不会成为注入点了。

2、普通文本

假如我要直接在div里面显示用户的输入的信息，譬如：

<div class='userName'><%=userName%></div>

这种情况，即使用户的userName是：

<script>alert("ok");</script>

我也必须可以显示出来，不能过滤这些字符。

那么解决方案就是解码加码。将

<>"'/

这些绝对有危险的字符采用

&#xxxx;

这种显示形式--当然，你也可以编写api来转换成为其他显示形式，必须确保白名单外面的所有字符都采用无危险的形式显示。

3、引用图片的脚本注入。

大家假如有试过的话，就可以知道在一幅图片里面加入一些脚本，譬如：

在图片1.png里面加入

<script>alert('ok');</script>

然后用

<img src='1.jpg'/>

哪些浏览器一定会中招？没错，ie6会中招，其他浏览器没试过。这种攻击的根源及解决方案是什么？

【下面引用一段话】

利用MIME 类型不匹配来进行HTML注入

　　IE具有许多令人惊讶的未公开特性，例如，IE7 以及之前的版本尝试加载一个图像或者其它的非HTML的响应并且失败时，它会将该响应作为HTML对待。为了弄明白这个情况，我们可以创建一个文本文件，并包含下列内容：

　　之后，将其保存为alert.jpg，然后在IE的URL地址栏中或一个iframe中装载的这个“图像”，这就会导致这里的JavaScript被执行。

　　注意，如果该文件是从一个图像标签加载的话，它就不会作为脚本执行了。

　　一般说来，当您试图上载这样的一个文件到一个图像托管服务时，该服务将拒绝这个文件，因为它根本就不是一个图像。但是图像托管服务通常情况下会忽视文件的扩展名，而只通过文件的幻数(开始几个字节)来确定文件类型。

　　因此，攻击者可以避开它，方法是用GIF注释中的HTML来创建一个GIF图像，然后将这个GIF保存为.jpg文件扩展名的文件。下面是一个单像素的GIF文件，如下所示：

　　00000000 47 49 46 38 39 61 01 00 01 00 80 00 00 ff ff ff |GIF89a..........|

　　00000010 ff ff ff 21 fe 19 3c 73 63 72 69 70 74 3e 61 6c |...!.. .|

　　00000030 2c 00 00 00 00 01 00 01 00 00 02 02 44 01 00 3b |,...........D..;|

　　将其命名为test.jpg，并在IE中加载它，这会导致执行这段JavaScript。这也是注入Flash跨域政策的一种好方法。只要把Flash安全策略的XML内容放入GIF注释，并保证这个GIF文件不包含扩展的ASCII字符或者字节NULL即可。您还可以把HTML注入到未压缩的图像文件(诸如XPM以及BMP文件)的图像数据部分，而不是注解中。

即：确保用户上传的图片的后缀名与文件的content-Type一致。

4.sql注入

什么，你的网站还有sql注入？现在不要用拼sql的方式来访问数据库了，即使拼sql，也要采用prepare方式，然后用参数啊。

【参考资料：http://sec.chinabyte.com/50/11409050.shtml】