以下是小编整理的专家谈：从iPad泄密事件看 Web应用安全WEB安全，本文共5篇，欢迎阅读与收藏。
篇1：专家谈：从iPad泄密事件看 Web应用安全WEB安全
我有一台iPad，实际上是两台，对此我感到很自豪，我的电子邮件地址也有很多人知道，而且经常有人向我发出请求，想要知道我的邮件地址。我猜他们一定发现像这样得到我的邮件地址不费吹灰之力。所以，前两天iPad泄露现有11.4万用户信息时，为什么会引起那么大的骚动？
让我们来看看到底发生了什么。
一个名为Goatse Security的 团伙发现了AT&T网站的一个安全漏洞，窃取了用户的ICC-ID(Integrated Circuit Card ID，IC卡识别码)并取得了与之相连的电子邮件地址。接下来，他们利用一段PHP代码反复向AT&T网站提供大量ICC-ID，然后取得相关电子邮件地址。就这样，他们得到了预计11.4万ICC-ID及其相关电子邮件地址。
我觉得大家都会觉得这是个问题，而且是个普遍存在的问题。在我们Foundstone的安全顾问服务中，经常会遇到我们称之为“信息公开”漏洞的问题。通过搜集用户或企业的这些信息，可以全面了解其正在使用的技术或用户行为。同时借助社会工程技术，就可以有效的获取一些原本无法得到的企业资源。
然而，这样的漏洞根本不算是最严重的漏洞。我们发现主要问题在于在Web应用程序的身份认证系统存在故障。也就是说，用户会话需要避免横向权限升级，因为横向权限升级将允许攻击者得到另一用户信息。所以，与其说这是iPad的漏洞问题，不如说是我们在进行应用安全评估时经常遇到的普通问题。
鉴于这个漏洞利用了一个Web应用程序缺陷，我认为应该总结一下在应用安全评估时最常见的5个问题。
授权失败
恶意认证用户可以接触它本无权接触的信息。通常这样会导致权限升级。如果权限升级发生在同级别的用户中，则被称为“横向权限升级”。如果用户可以将权限升级至更高级别用户，即为“纵向权限升级”。在AT&T事件里，结果只是信息泄露，而没有权限升级。
跨站点脚本 (XSS)
跨站点脚本攻击需要攻击者在应用程序的数据领域中输入恶意代码（通常是Java脚本），而这些数据领域对该应用程序的其他用户而言也是可见的。当受害用户浏览该数据领域时，该Java脚本就在该用户浏览器中运行，并执行一些对攻击者有用的功能。反向XSS攻击通常用来进行钓鱼攻击。
跨站点请求伪造 (XSRF)
跨站点请求伪造攻击（也叫XSRF，CSRF，或者会话控制）允许恶意用户执行对攻击者选定的用户会话的操作，从而泄露用户信息。这类攻击利用了HTTP无状态的弱点。
密码重置功能
通常来说，应用程序允许用户在忘记密码的情况下重置密码。密码提醒/重置程序通常很容易成为被攻击的对象。很多情况下，攻击者首先列出所有具有同样特征的有效用户名。一旦这些用户名中有一个被辨认出来，那么密码问题的答案都可以猜出来。一般情况下，在密码重设页面没有输入次数的限制。而且用户在社交网站上设置的一些问题的答案也可能被攻击者猜中。
SQL注入
SQL注入允许攻击者在关系数据库里执行任意SQL语句。通常，漏洞出现通常都是源于应用程序SQL查询的不安全构造。即使在数据验证很少或没有的情况下，应用程序也会信任攻击者提供输入的信息，执行任意的恶意SQL语句。成功的SQL注入攻击可以泄露基础操作系统信息。
建议
尽管现在是“应用程序101”，我们仍然可以在每一份应用程序安全测评报告中看到几乎所有的5个问题。下面是几条建议：
授权失败
会话应该使用基础框架提供的会话容器。为了避免横向权限升级，应用程序需要对以下三点进行三次确认：
需确认的授权内容：
主体：例如用户或群组
操作：例如CRUD —— 创建、读取、更新、删除
客体：例如数据因素（账号、购物卡ID等）
跨站点脚本 (XSS)
为了避免诸如跨站点脚本等数据验证攻击，我们建议采取“深层防御”策略，包括输入验证和输出消毒，
阻止数据验证攻击的第一步就是要验证输入来防止接受任何在该应用程序中或数据终端（也就是浏览器）中有特殊意义的语句。我们推荐的输入验证方式是“默认拒绝”，只接受含有预期值（也就是白名单）的输入。日常输入验证必须始终检查数据长度、范围、类型和格式。
消毒应用程序HTML中的恶意语句与防止跨站点脚本攻击（XSS）同等重要。比如，“<”应编码为“<”；尽管对于用户来说，这是“少于”的意思，但是它不会被用户浏览器解释为HTML标签的起始点。
跨站点请求伪造 (XSRF)
要防止XSRF攻击，一种有效而又不唐突的方法就是在每一个可以改变某些外在状态的表格中引入一个“随机数”，或者一次性口令。每次用户加载表格，一个不同的“随机数”就 入表格中的一个隐藏区域内。当表格提交后，应用程序检查该随机数是否有效，然后再运行所请求的操作。“随机数”可以是现有会话的标识信息，这种信息一般都会附加在每个请求之后。不过，只有当目标应用程序不存在任何XSS漏洞的情况下，这种方法才能有效。
另外一些更加不唐突的避免XSRF的方法包括使用“Captchas”、对重要操作重新授权、或使用独立授权密码。这些方法很有效，但也会给用户带来额外负担。从用户界面角度来看，这些方法并不常用。
密码重置功能
密码重置功能的推荐方法是：
1.这种方法需要用户输入用户名。把下面信息传递给终端用户，“如果用户名与系统中的现有账户吻合，一封写有下一步说明的电子邮件将发至账户所有者的注册电子邮件地址。”
2.这封电子邮件必须含有唯一的、带有时间限制的链接（比如，24小时内有效），而且只能由用户点击一次。
3.点击链接后，用户将看到几个问题。
4.成功回答问题后，用户将被允许修改其密码，同时对应用程序进行授权。
SQL注入
防止SQL注入攻击需要采取“深层防御”策略。第一步是使用阻止XSS攻击中提到的白名单方法进行输入验证。
除此之外，还需要使用与动态SQL相反的参数查询用。参数查询可以将查询与数据分离，支持数据库引擎在数据缺失情况下决定运行查询的最佳方法。数据将由查询执行计划在运行时间内使用，保证查询执行计划不会被恶意数据修改。
结束语
我猜这个应用程序漏洞之所以得到如此关注，是因为，毕竟我们所谈论的是苹果。围绕苹果产品的炒作，比如对iPhone和iPad的炒作，令人震惊。然而事实是，这种漏洞其实并不是什么新闻，而是每天都在我们身边发生。
现在，很多应用程序并没有经过全面测试便推向市场。考虑到很多企业目前面临的市场压力，这种现象就变得一点都不奇怪。所以，尽管我认为这个漏洞并不像媒体渲染的那样严重，但是它还是让我们看到一个好的安全程序和生命周期研发操作是成功的关键。
在上面提到的最常见的5种Web应用程序漏洞中，很多都可以通过计划和安全测试来消除。你所面临的最大挑战就是说服你的老板，让他相信这些漏洞确实存在。不过我想现在你又多了一种有力武器来达到目的。
注释：作者George Kurtz，现为迈克菲首席技术官。
篇2：PHP开发web应用安全总结
XSS跨站脚本
概念：恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的，
危害：
盗取用户COOKIE信息。
跳转到钓鱼网站。
操作受害者的浏览器，查看受害者网页浏览信息等。
蠕虫攻击。
描述：反射型跨站。GET或POST内容未过滤，可以提交JS以及HTML等恶意代码。
代码：
//正常URL
user.php?msg=henhao
//带JS的URL
user.php?msg=
//恶意跳转URL
user.php?msg=
解决方法：
输出过滤，php端输出到view的模板页面上的数据都需要经过过滤：
//输出过滤HTML JS标签
$var = str_replace(array('
$var = addslashes($var);
CSRF跨站攻击
概念：CSRF跨站请求伪造，也被称成为“one click attack”或者session riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。
危害：强迫受害者的浏览器向一个易受攻击的Web应用程序发送请求,最后达到攻击者所需要的操作行为。
例子：
1. 上面是一个图片的html标签，但是src中是一个添加id为123好友的新增好友链接。
2. 恶意用户可以将这段代码植入其它网站网页上面，甚至可以img设置为0,0，让用户不知不觉中点击这个链接，达到用户并不像加这个人好友，但是添加的目的。
3. 当很多人都无意加了id为123这个人为好友的时候，id为123的恶意用户就有权限来查看这些人的信息，甚至可以发送很多恶意的信息，达到恶意用户的目的。
解决方法：
1. /addfriend.php?id=123 使用POST方法会相对安全一点。
2. 采用类似随即码或者令牌的形式，让用户操作唯一性。 （每次用户登录网站随机生成一个token，存放在cookie中，用户的所有操作中都需要经过token验证）
flash安全问题
例子：
images.sohu.com/bill/s/liulin/nokia/1602600902.swf?clickthru=javascript.:alert(1)
解决方法：
在网站根目录中，添加crossdomain.xml文件，这个文件主要是控制flash的域访问。
淘宝的：www.taobao.com/crossdomain.xml
sql注入安全问题
概念：所谓SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。
危害：
1. 查询数据库中敏感信息。
2. 绕过认证。
3. 添加、删除、修改服务器数据。
4. 拒绝服务。?id=(BENCHMARK(100000000, MD5(RAND));
例子：
$sql = “SELECT name FROM users WHERE id = '”. $_GET['id'] . “'”;
当ID值为：1’or 1=’1 SQL语句(已测试可以注入)：
SELECT name FROM users WHERE id = ‘1’ or 1=’1 ‘
说明：1=1的时候，条件语句WHEREOR之前的不起作用。 ‘的作用是组装SQL语句。
解决方法：
SQL组装的时候，对外部变量以及所有变量都进行过滤：
PHPWIND中，可以用sqlEscape、sqlImplode、sqlSingle、sqlMulti等函数过滤组装。过滤主要是一些’单引号这些可以破坏SQL组装的数据。
/**
* SQL组装-私有SQL过滤
* @param string $val 过滤的值
* @param int $iskey 0-过滤value值，1-过滤字段
* @return string
*/
private function build_escape_single($val, $iskey = 0) {
if ($iskey === 0) {
if (is_numeric($val)) {
return “ '” . $val . “' ”;
} else {
return “ '” . addslashes(stripslashes($val)) . “' ”;
}
} else {
$val = str_replace(array('`', ' '), '', $val);
return ' `'.addslashes(stripslashes($val)).'` ';
}
}
XML注入安全问题
概念：和SQL注入原理一样，XML是存储数据的地方，如果在查询或修改时，如果没有做转义，直接输入或输出数据，都将导致XML注入漏洞，
攻击者可以修改XML数据格式，增加新的XML节点，对数据处理流程产生影响。
危害：
1. 攻击者可以新增XML节点
2. 破坏原来的XML结构，影响业务流程，甚至产生严重的错误。
例子：
$xml = “
需要得到的XML结构：
恶意代码：
user1@a.com
意外的XML文档：
解决方法：
1. 对php处理XML文档的时候，进行标签过滤
2. 尽量减少直接被外部访问到xml文档，可以采用文件名用散列方法等。
url跳转漏洞
概念：Web应用程序接收到用户提交的URL参数后，没有对参数做”可信任URL”的验证，就向用户浏览器返回跳转到该URL的指令。
危害：钓鱼网站
例子：
m.yahoo.cn/log.php?c=web&u=www.163.com
解决方法：
对跳转的php函数进行进一步优化，使页面跳转可以在可信任的范围内。 例如可以有跳转域名白名单方法，这个访问各大公司使用比较多
文件系统跨越漏洞
概念：对文件目录参数没有进行过滤，导致恶意用户可以通过在参数中输入一些执行命令，或者跨越访问的行为，来超出用户的访问权限。
例子：通过一个或多个../跨越目录限制
$fp = fopen(“image/{$_GET['filename']}”, 'r');
Getfile?filename=../../../../etc/passwd
解决方法：
1. 对文本操作的时候一定要谨慎，不可信任
2. 严格使用phpwind中安全类库escapePath函数
系统命令漏洞
概念：用户提交的参数用于执行系统命令的参数。
解决：
1. 谨慎使用系统命令，对使用系统命令的地方需要进行安全评审
2. 对命令语句进行严格过滤
文件上传漏洞
概念：Web应用程序在处理用户上传的文件时，没有判断文件的扩展名是否在允许的范围内，或者没检测文件内容的合法性，就把文件保存在服务器上，甚至上传脚本木马到web服务器上，直接控制web服务器。
情况：
1. 未限制扩展名
2. 未检查文件内容
3. 病毒文件
解决方法：
1. 使用安全的，可信任的上传组件。
2. 检查文件扩展名，保证文件的类型正确。
3. 检查文件内容，保证用户不伪造文件类型。
任意文件下载漏洞
解决方法：
1．Apache虚拟目录指向
2．Java/PHP读取文件
权限控制漏洞
概念：属于业务逻辑上的安全管理。
访问控制：
1. 水平访问：Web应用程序接收到用户请求，修改某条数据时，没有判断数据的所属人，或判断数据所属人时，从用户提交的request参数（用户可控数据）中，获取了数据所属人id，导致恶意攻击者可以通过变换数据ID，或变换所属人id，修改不属于自己的数据。
2. 垂直访问：由于web应用程序没有做权限控制，或仅仅在菜单上做了权限控制，导致的恶意用户只要猜测其他管理页面的URL，就可以访问或控制其他角色拥有的数据或页面，达到权限提升目的。
存在情况：
1．URL级别的。（例如论坛需要操作评分的时候，有一个提交的URL地址，该地址提交过去，如果不做权限判断，那么恶意用户就可以随意的拿这个URL地址来进行恶意行为）
2． 菜单级别。（会员中心或者后台管理中心，会有菜单，管理员可以看到多个功能，普通管理员只能看到一部分功能。但是如果你对管理员操作的功能区不做权限判断，那么普通管理员只要猜测或者获取管理区的URL，就可以进行管理员操作了）
危害：
1. 属于业务逻辑的漏洞，这些危害性是巨大的，可以让普通用户就可能获取管理员的权限，对网站进行恶意破坏或者做非法行为。
解决方案：
1. 项目先期，做一份详细的权限规划文档。
2. 在开发中严格按照权限文档的要求去做权限。
3. 后期测试需要覆盖权限这一块功能区。
4. 程序员需要经常注意这些方面的要求。
cookie安全设置
解决：
cookie httponly flag ： 在用到用户名登陆密码之类的安全性比较高的cookie的时候，可以在cookie中设置httponly属性，该属性只允许php等访问cookie，而不允许js访问。
cookie secure flag ： 在涉及到https这样的情况，需要对cookie加密传输，那么可以设置这个属性
session安全
1. SESSION是保存在服务器端的，具有比COOKIE一定的安全性。
2. 使用COOKIE的时候，如果长时间没有动作，可以设置一个时间值，来对COOKIE进行过期。
3. 尽量让用户每次的cookie值都是不同的，这样可以保证cookie被盗取也不能长期使用的问题
作者 initphp的LAMP开源世界
篇3：如何保障Web服务器安全
如何保障Web服务器安全
维护Web服务器安全是信息安全中最不讨好的差事之一，你需要在相冲突的角色中找到平衡，允许对网络资源的合法访问，同时阻止恶意破坏。
你甚至会考虑双重认证，例如RSA SecurID，来确保认证系统的高信任度，但是这对所有网站用户来说也许不实用，或者不划算。尽管存在这样相冲突的目标，仍有六个有助Web服务器安全的步骤。
对内部和外部应用分别使用单独的服务器
假设组织有两类独立的网络应用，面向外部用户的服务和面向内部用户的服务，要谨慎地将这些应用部署在不同的服务器上。这样做可以减少恶意用户突破外部服务器来获得对敏感的内部信息地访问。如果你没有可用的部署工具，你至少应该考虑使用技术控制(例如处理隔离)，使内部和外部应用不会互相牵涉。
使用单独的开发服务器测试和调试应用软件
在单独的Web服务器上测试应用软件听起来像是常识——的确是。不幸的是，许多组织没有遵循这个基本规则，相反允许开发者在生产服务器上调试代码甚至开发新软件。这对安全和可靠性来说都很可怕。在生产服务器上测试代码会使用户遇到故障，当开发者提交未经测试易受攻击的代码时，引入安全漏洞。大多数现代版本控制系统(例如微软的Visual SourceSafe)有助于编码/测试/调试过程自动化。
审查网站活动，安全存储日志
每一个安全专业人员都知道维护服务器活动日志的重要性。由于大多数Web服务器是公开的，对所有互联网服务进行审核是很重要的。审核有助你检测和打击攻击，并且使你可以检修服务器性能故障，
在高级安全环境中，确保你的日志存储在物理安全的地点——最安全的(但是最不方便的`)技巧是日志一产生就打印出来，建立不能被入侵者修改的纸记录，前提是入侵者没有物理访问权限。你也许想要使用电子备份，例如登录进安全主机，用数字签名进行加密，来阻止日志被窃取和修改。
培训开发者进行可靠的安全编码
软件开发者致力于创建满足商业需求的应用软件，却常常忽略了信息安全也是重要的商业需求。作为安全专业人员，你有责任对开发者进行影响到Web服务器的安全问题的培训。你应该让开发者了解网络中的安全机制，确保他们开发的软件不会违背这些机制;还要进行概念的培训，例如内存泄漏攻击和处理隔离——这些对编码和生成安全的应用软件大有帮助。
给操作系统和Web服务器打补丁
这是另一个常识，但是当管理员因为其他任务而不堪重荷时常常忽略这一点。安全公告，像是CERT或者微软发布的公告，提醒人们软件厂商多频繁地发布某些安全漏洞的修补程序。一些工具像是微软的软件升级服务(SUS)和RedHat的升级服务有助于使这项任务自动化。总之，一旦漏洞公布，如果你不修补它，迟早会被人发现并利用。
使用应用软件扫描
如果负担地起，你也许会考虑使用应用软件扫描器来验证内部编码。像是 Watchfire公司的AppScan这样的工具有助于确保编码在生产环境里不会存在漏洞。记住，要有安全意识。设计良好的 Web服务器结构应该基于健全的安全政策。贯彻执行这六个方法会帮助你建立坚固的基础。
篇4：Web安全测试知多少
1. 数据验证流程：一个好的web系统应该在IE端，server端，DB端都应该进行验证，但有不少程序偷工减料，script验证完了，就不管了;app server对数据长度和类型的验证与db server的不一样，这些都会引发问题。有兴趣的可参看一下script代码，设计一些case，这可是你作为一个高级测试人员的优秀之处哦。我曾修改了页面端的script代码，然后提交了一个form，引发了一个系统的重大漏洞后门。
2. 数据验证类型： 如果web server端提交sql语句时，不对提交的sql语句验证，那么一个 就可暗喜了。他可将提交的sql语句分割，后面加一个delete all或drop database的之类语句，能将你的数据库内容删个精光!我这一招还没实验在internet网站上，不知这样的网站有没有，有多少个。反正我负责的那个web系统曾经发现这样的问题。
3. 网络加密，数据库加密不用说了吧。
WEB软件最常碰到的BUG为：
1、SQL INJETION
2、对文件操作相关的模块的漏洞
3、COOKIES的欺骗
4、本地提交的漏洞
SQL INJETION的测试方法
原理：
如有一新闻管理系统用文件news.asp再用参数读取数据库里的新闻譬如
www.xxx.com/news.asp?id=1这一类网站程序
如果直接用
rs.open “select * from news where id=” &
cstr(request(“id”)),conn,1,1
数据库进行查询的话即上面的URL所读取的文章是这样读取的
select * from news where id=1
懂得SQL语言的就知道这条语言的意思是在news读取id为1的文章内容。
但是在SQL SERVER里select是支持子查询和多句执行的。如果这样提交URL的话
www.xxx.com/news.asp?id=1and 1=(select count(*) from admin
where left(name,1)=a)
SQL语句就变成了
select * news where id=1 and 1=(select count(*)
from admin where left(name,1)=a)
意思是admin表里如果存在字段字为name里左边第一个字符是a的就查询news表里id为1的内容，news表里id为1是有内容的，从逻辑上的角度来说就是1&P。只要P为真，表达式就为真，页面会返回一个正确的页面。如果为假页面就会报错或者会提示该id的文章不存在。 利用这点就可以慢慢得试用后台管理员的用户和密码，
测试：
测试存不存在SQL INJETION很简单如果参数为整数型的就在URL上分别提交www.xxx.com/news.asp?id=1and 1=1 和www.xxx.com/news.asp?id=1and 1=2
如果第一次返回正确内容，第二次返回不同页面或者不同容内的话表明news.asp文件存在SQL INJETION。如何利用就不多说了，毕竟我们都不是为了入侵。
对文件操作相关的模块的漏洞在测试
原理：
如一上传文件功能的程序upload.asp如果程序员只注重其功能上的需求没有考虑到用户不按常规操作的问题。如上传一个网页木马程序上去，整个网站甚至整个服务器的架构和源码都暴露而且还有一定的权限。
测试：
试上传asp,php,jsp,cgi等网页的文件看是否成功。
补充：
还有像 www.xxx.com/download/filespath.asp?path=../abc.zip
下载功能的软件如果
www.xxx.com/download/filespath.asp?path=../conn.asp
很可能下载到这些asp的源码数据库位置及用户密码都可能暴露。
其它还有很多，就不一一举例了。
COOKIES的欺骗
原理：
COOKIES是WEB程序的重要部分，COOKIES有利有弊。利在于不太占用服务器的资源，弊在于放在客户端非常容易被人修改加以利用。所以一般论坛前台登陆用COOKIES后台是用SESSION，因为前台登陆比较频繁，用SESSION效率很低。但如论坛程序管理员用户在前台也有一定的权限，如果对COOKIES验证不严的话，严重影响了WEB程序的正常工作。如前期的LEADBBS，只有后台对COOKIES验证严格，前台的位置只是从COOKIES读取用户的ID，对用户是否合法根本没有验证。
测试：
推荐使用MYBROWER浏览器，可即时显示及修改COOKIES。尝试一下修改里面的对应位置。
本地提交表单的漏洞
原理：
Action只接爱表单的提交，所以表单是客户WEB程序的接口。先举一个例子，一个投票系统，分A，B，C，D各项的VALUE是100,80,60,40。
但是如果先把些页面以HTML形式保存在本地硬盘里。然后修改其VALUE，再向其ACTION提交，ACTION会不会接受呢?
测试：
如一投票系统，把投票的页面保存在本地硬盘，用记事本打开，找到对应项的VALUE值，对其修改，然后提交。
强制后台浏览：绕过登陆页面，直接提交系统文件夹或文件页面。不完善的系统如果缺少index.html就可能被绕过登陆验证页面。在系统文件夹中保留一些公司机密内容也会造成不可估计的损失。
跨站脚本攻击：基本上这个我只是在论坛――各种形式的论坛里看到过，具体的一个例子，比如这段代码可以被填在任何输入框里 “”，如果未对一些字符，如 “<”、“>”进行转换，就会自动执行这个脚本。百度快照所提供的网页都自动将代码执行了。不信大家搜一点JS的代码，看看你能不能看到。
堆栈溢出攻击：完全的不了解，只是在某个网站上看到，可以对现在的、XP、进行攻击，非常恐怖，MS应该打了补丁了吧?
篇5：Web.config 安全相关配置WEB安全
web.config 位于根目录
1、authentication节点
基于窗体（Forms）的身份验证配置站点，当没有登陆的用户访问需要身份验证的网页，网页自动跳转到登陆网页。其中元素loginUrl表示登陆网页的名称，name表示Cookie名称
2、authorization 节点
allow 向授权规则映射添加一个规则，该规则允许对资源进行访问。
deny 向授权规则映射添加一条拒绝对资源的访问的授权规则。
users=“*” 是指任何用户 users=“?” 是指经身份验证的用户
注意: 运行时，授权模块从最本地的配置文件开始，循环访问 allow 和 deny 元素，直到它找到适合特定用户帐户的第一个访问规则。然后，该授权模块根据找到的第一个访问规则是 allow 还是 deny 规则来允许或拒绝对 URL 资源的访问。默认的授权规则为 。因此，默认情况下允许访问，除非另外配置。
如果在根目录下的web.config配置太繁琐，可以配置到相应目录下，例如User目录下的web.config文件
3、customErrors 节点
mode=“On|Off|RemoteOnly”>
defaultRedirect 可选的属性。指定出错时将浏览器定向到的默认 URL。如果未指定该属性，则显示一般性错误。
Mode 必选的属性。指定是启用或禁用自定义错误，还是仅向远程客户端显示自定义错误。
此属性可以为下列值之一。
值 说明
On 指定启用自定义错误。如果未指定 defaultRedirect，用户将看到一般性错误。
Off 指定禁用自定义错误。这允许显示标准的详细错误。
RemoteOnly 指定仅向远程客户端显示自定义错误并且向本地主机显示 ASP.NET 错误。这是默认值。
默认值为 RemoteOnly。
error 可选的元素。指定给定 HTTP 状态代码的自定义错误页。错误标记可以出现多次。子标记的每一次出现均定义一个自定义错误条件。
例如：
这里可以让用户自定义出错页。
4、pages 节点
validateRequest=“true”
该值确定 ASP.NET 是否针对危险值检查来自浏览器的输入。如果 ASP.NET 针对危险值检查来自浏览器的输入，则为 true；否则为 false。默认值为 true。
这个功能是为了防止跨站脚本等危险代码。使全局默认为true。只有小数页面，如搜索页面
Search.aspx 设为 : ValidateRequest=“false” 。为了可以搜索类似 等内容，如果只是文字性的输入，可修改页 search.aspx 的设置，以增强系统安全性。
Security.config 配置说明
文件位于config目录
1、后台页面访问配置
noCheckAdminLogOn
后台不检查权限的页面
2、检查外站链接的后台页面配置
noCheckUrlReferrer
后台不检查来源页的列表，即管理员用户可以直接访问的文件列表，
后台设置是默认不允许直接访问，这样可以保护后页页面不被非法方式访问和外站链接访问，有效防止跨站请求伪造。
如果文件不在列表中，直接在URL 里访问，将出现错误提示：
产生错误的可能原因：
对不起，为了系统安全，不允许直接输入地址访问本系统的后台管理页面。
如需要，用户可以加上自定义的内容。
3、防止跨站请求伪造追加安全码的页面配置
checkSecurityCode
页面提交时检查安全码。
防止不正常操作（恶意操作）造成系统重大损失。也是对一些重要操作的保护，防止跨站请求伪造。
如：
4、页面操作权限码的配置
checkPermissions
页面操作权限码的配置，检查后台管理员是否有相关操作码的权限。
operateCode 为操作码 根据操作码判断是否存在此操作的权限。
checkType 权限判断类型， or and
or 操作码中的权限进行或运算，即有其中任何一种权限，就返回true
这个默认值是or 而且对于单一权限码的,可以不用配置
and 操作码中的权限进行与运算,即要求有全部权限才返回true 否则返回false.
AjaxLabel.config 配置说明
是对AJAX.aspx 的文件访问权限控制配置文件。
由于前台AJAX标签过于强大，会致使 AJAX标签 会出现一些危险性，对此我们做了一个XML安全文件来配置那些AJAX标签可以直接引用。这个AjaxLabel.config 文件是在 网站根目录的Config 目录下。如果标签没有记录，就会出现 本标签禁止访问！
例如:
是指标签名 为 “内容评论PK标签” 的标签可以被ajas.aspx调用，而且参数param只能为 “generalid”,类型为Int，这样能有效防止恶意攻击。
如果用户需自定义标签，而且需要ajax.aspx 文件调用，那就在AjaxLabel.config 中配置
app_offlineX.htm 文件作用
如果你要COPY站点，进行站点维护，部署，和进行大量修改，有可能要停掉你的WEB应用程序了，而以一个友好的方式提示给用户，比如什么“本网站正在更新”等等的信息,你可以把文件app_offlineX.htm 改名为app_offline.htm(大小写没关系）的静态HTM页面文件，其中修改成你要临时显示的内容，将其放在你的应用的根目录下。这样，任何外部的请求的话，都会马上被转移到该页面了。
网站维护完成后记得将文件名app_offline.htm改回。
AllowString.xml 文件配置
文件位于Common目录下
文件的作用是：会员发表信息时启用防XSS（跨站攻击）设置时，让用户设置允许会员提交部份特殊js 代码。
XSS是指攻击者利用网站程序对用户输入过滤不足，输入可以显示在页面上对其他用户造成影响的HTML代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。
例如：
功能是： 允许保留 nmousewheel=“return bbimg(this)” 和 nload=“resizepic(this)” 代码。这是对FCK上传图片功能的一个保留。
如用户想让系统过滤不要太严格，可在这里加上相应保留代码。
★Linux下PhpMyAdmin程序目录的安全管理WEB安全
文档为doc格式
