一, 数据库安全性
1， MS SQL Server数据库安全性
Web中不允许使用sa级的用户连接数据库
解决方法：
删除sa用户，新建一个权限为sa的用户，用户名和密码一样要复杂。以防暴力破解。
新建一个web连接用户，去掉所有服务器角色，在用户映射中加入此用户要操作的数据库和db_public身份。
假如需要其它操作要另加权限（如只加insert/delete/select/update）。
每个人都没法保证自己写的代码没有漏洞。只要在数据库层做下处理以防入侵。假如有SQL注入db_public身份一样能对数据库添加/修改/删除权限，所以一定不能存在SQL注入漏洞。
假如能防SQL注入和权限限制就很难发生暴库/跨库现像。
2， Access数据库安全性
解决方法：
防暴库：在数据库连接时加入错误处理代码，假如数据库连接失败就提示错误信息或转向。不能由系统本身提示错误信息，
防下载。
第一步：新建一个表。
第二步：在表中建一个字段，名称随意，类型是OLE对象，然后用ASP代码向字段中添加一条记录写入单字节的"<%" 代码为：Insert into tablename(fieldname) value (chrB(asc("<")) & chrB(asc("%")))。
第三步：将数据库改名为*.ASP
最安全的方法是用使用ODBC数据源连接
二， web代码安全性
1， 备份文件时的小漏洞。
有些ASP编辑器会自动备份asp文件，并且改名为*.bak，这样就存在了会被下载的漏洞,在给asp文件改名时，不要修改为*.txt/.bak/等等，一定要保存扩展名不变（*.asp），在上传到站点时请不要上传备份文件。
2， 防SQL注入。
SQL注入主要是单引号没有过滤，让人利用，重新生成一个具有威胁性的SQL语句。
如：http://www.livexy.com/view.asp id=100 假如存在SQL注入我们就可以这么写：http://www.livexy.com/view.asp id=100 ;delete * from tablename;后台运行时为select * from aaa where;delete * from tablename
在这里要提醒大家，不要认为.net的安全性高就没有SQL注入了。错，只要和数据库操作有关的都存在SQL注入漏洞。无论是软件还是网站，都存在。
解决方法：
在页面的开始位置过滤接收到的非法字符，如exec /delete /insert into/update/’ 等等，这里过滤不是指将非法字符过滤为空串，而是过滤为相近的字符。或者假如存在非法字符则转向到错误处理页面。这里说个例子假如将exec过滤为空串时会出来什么后果，假如字串中存在exexecec 请问过滤后是什么，还是exec。这里不多说了，大家都明白了哈。
假如接收参数为数值型时，必需要先判断数据类型，以防出现其它错误。往往黑客信息的来源就是页面出错的信息。
假如参数为字符型时，必需要过滤字符串中的单引号为双引号或其它字符。
这里写个例子：往往我们的代码都是这么写的select * from aaa where bbb=’” + sVal +”’” 表面上看是没有问题的，是正确的，不过此句存在SQL注入。为什么呢，请看：sVal的值是外部提交的数据，假如sVal的值为aaa’;delect * from bbb;-- 写在一起就是：select * from aaa where bbb=’ aaa’;delect * from bbb;--‘其中-- ‘为注释。
使用DbParameter比拼接SQL来的完全的多。
3， 登录漏洞。
解决方法：
过滤非法字符串
SQL写法
select password from user where username=’” + sqlstr(sUser) + “’”
其中sqlstr()为过滤非法字符串函数，sUser为用户名文本框中输入的字符。然后在判断数据库中的密码和输入的密码是否一致。 原理：由用户名在数据库中找到此用户的记录，然后在用密码比较。千万不要用“select * from user where username=’” + sqlstr(sUser) + “’ and password=’” + sqlstr(sPass) + “’” 然后在判断是否为空。”这种方法。 4， 防另存为 解决方法： <NOSCRIPT><IFRAME SRC="*.html"></IFRAME></NOSCRIPT>
防止别人下载网站的HTML代码，当然不是很完美，不过也够呛。 5， 防被内嵌 解决方法： <script>if (self != top) { top.location = self.location; }</script>
防止别人内嵌我们的网站，然后做些手角。如键盘记录呀，监视我们输入的数据呀等等。 6， 防本地提交数据 解决方法： 在保存数据时第一步判断来源，假如不是从指定的来源提交数据，出示错误信息。 第二步对提交数据进行非法字符过滤。 第三步保存到数据库，保存时一定要进行错误处理。 7， 防无限刷新 解决方法： 这个比较难做，当然也有很多种方法。 1，在服务器上做手角 2，在代码中加入访问日志信息，通过分析日志信息来判断同一人访问频率。 3，用js操作cookies来记录访问日志信息，判断访问频率。这种方法不会占用服务器的资源。 8， 防无限提交数据/防ajax自动提交数据 解决方法： 加入验证码和提交时间（如一分种发信息）限制功能。 9， 防js代码 解决方法： 要想过滤所有js代码这点很难办法，js攻击漏洞占大多数。Js的写法也千奇白怪。这里发上一些具有攻击性的html代码。这些都是常见到的，并且每一种都不同的写法。单引号和双引号不同/大小写不同/先后循序不同/tab和空格不同/Html标签不同/事件不同/样式不同等等。 <P style="BACKGROUND:url(JAVA SCRIPT:alert('11111'))">test</P> <body> <img src="http://www.challenger.se/images/note_yellow.gif"/> <img src="JAVASCRIPT:alert('888888')" /> <STYLE>div{behavior: url("htc.js");};<style> <STYLE>body{oMouseOut: eXpreSsIon(onclick = function(){alert('33333');})} <style> <STYLE>body{background:url(JAVASCRIPT:alert('22222'));} <style> <STYLE>@import "JAVASCRIPT:alert('444444')"; <style> <link href="JAVASCRIPT:alert('777777')" rel="stylesheet" /> <script src= hk.js></script> <P style="BACKGROUND:url(JAVASCRIPT:document.write('<script src=hk.js></script>'))">test</P> <iframe src='hk1.html'></iframe>
10，防Cookie假冒 解决方法： 密码信息不要存放在Cookie中 在用到Cookie中的数据时，一定要从数据库中重新读取。然后比较。以防Cookie篡改。 Cookie数据需要加密 11，缓冲区溢出 解决方法： 服务器中不要打开无用软件。 在服务端运行的代码中，用到一个对像一定要释放。 在客户端运行的js/vbs/activex/flash代码中，用到的dom对像在结束时一定要释放。 12，其它 防浏览器插件 修改IE的安全选项把“活动脚本”和ActiveX的运行设置为禁用或提示。 或在IE安全设置里将安全级别设为高。隐私选项也设为高。 三， 服务器安全性 关闭无用端口 下载补丁/更新操作系统 安装杀毒软件 安装防火墙 假如服务器上有多个站点，为每一个站点分配权限，每个站点都不能操作其它文件和目录，也不能影响到其它站点。 注意：其实以上内容大家都知道，哪么为什么还会出现这么多漏洞呢。有时候我和其它的同伴常说一些费话，我常常会说单引号过滤了吗，回答是都过滤了，我又说请再看一遍回答我，回答的还是都过滤了，当我看时依然是没有完全过滤。这能反应一个什么问题大家都明白了吧。因为大家在写代码时写法都是select * from aaa where bbb=’” + sVal +”’”已成习惯。其实我也常犯这个错误，所以特别在这里提出。这就是重重之重。 原文标题：web安全问题汇总 链接：http://www.cnblogs.com/livexy/archive/2010/07/07/1773199.html