《Web应用安全权威指南》读后有感

下面是小编为大家推荐的《Web应用安全权威指南》读后有感，本文共9篇，欢迎阅读，希望大家能够喜欢。本文原稿由网友“哆啦Q梦”提供。

篇1：《Web应用安全权威指南》读后有感

v1nc3nt

这本书前前后后读了有一个多月，中途还有一个国庆七天小长假，所以时间说长也长。第一次加入图灵读者群，在大家的互相监督下完成读书任务，感觉很奇妙。前后打卡一天没落下，最后应该是打卡总天数第二。

很感谢有这么一个平台，能够监督着我们的学习进度，还要感谢众多大佬的无私解答，让我实实在在地感受到了安全圈的自由与分享精神。说了这么多，下面就谈谈我对这本书的一些感受和收获吧。

读过图灵的日系书，比如《图解TCP/IP》，能感觉到日本人写作的风格与西方的差异。整体给人感觉很严谨很仔细，有时可以说是有点嗦了。当然，这并没有任何的贬义。相反，这对于新手入门来说，是一大利好。新手入门往往充满着敬畏与迷茫，如果上来就是各种大术语，高精尖的漏洞利用，往往会让人望而生畏，失去了继续学习的动力。

这本权威指南总的来说还是很不错的，对Web漏洞这块的讲解翔实仔细，分类也是比一般的书更为精细，如果通篇读下来，对Web漏洞的原理以及基本防范措施，能够做到心中有数。

全书共分为8章，重点是第四章“Web应用的各种安全隐患”，我自己读这章也花时间最多。前面的包括搭建环境、同源策略、HTTP协议这些都比较熟悉，所以很快地浏览完了。关于第四章的漏洞讲解，我也基本上同时参照了所给的虚拟机环境以及 Fiddler，进行了同步的操作。

原来对 XSS SQL 注入 CSRF 这些都有过了解，但是仅限于一些简单的构造和利用，对前后台交互层面的原理不得而知，阅读完这几章之后，有了更加深刻的认知。当然深知这是不够的，以后的打算是进一步深刻理解这些漏洞原理，通过 Kali Linux 的相关工具在实战中练习这些漏洞的利用。

同时工具不能仅限于使用，还要明白其底层原理。自己也同时在学习Python，准备重点是网络编程这块，利用好自带的安全的库，尝试写一些工具脚本。学习是一个循序渐进的过程，读完一本书并不仅限于学到其中的知识，而是将原来一知半解的东西弄懂，并且对未来的'学习路径有了更清晰的认知。能够调整节奏与方向，更好地完成知识积累，并完善技术栈。

当然，这本书也存在一些个人认为的缺陷。书是日本作家写的，虚拟机环境也是日文的，如今翻译成中文版，虚拟机应该也做相应的调整。满眼的日文，确实是不太友好。希望日后能够改善，为入门者提供一个更加和谐 、友好的实战环境。

以上是本人在读罢《Web应用安全权威指南》的一些感受，个人所感，文笔与水平有限，望各位大佬多多指教。最后，感谢图灵教育的帮助与支持，为各位安全入门的同学提供了这么好的学习讨论平台。感恩！

篇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('<','='), array('..',')','<','='), $var);

$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 = ““ . $_GET[‘name’] . ”“ . $_GET[‘email’] . “”;

需要得到的XML结构：

user1

user1@a.com

恶意代码：

user1@a.comtestuser2@a.com

意外的XML文档：

user1

user1@a.com

test

user2@a.com

解决方法：

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：如何应用份认证模块和.htaccess文件保证Web安全

要限制对一个网页的访问，可使用Apache和第三方提供的身份认证模块和方法来验证用户的凭据(如用户名和密码)，一些模块支持通过各种数据库(包括NIS和LDAP)进行身份认证。

用户认证指令通常放置在.htaccess文件中。下面是使用Apache默认身份认证模块(mod_auth)的一个基本.htaccess文件。当这个文件放置在/var/www中时，会导致Apache要求用户输入密码进行验证，然后浏览器才能访问/var/www目录层次结构中的内容。应用时，要用本地服务器的相应值进行替换。

# cat .htaccess

AuthUserFile /var/www/.htpasswd

AuthGroupFile /dev/null

AuthName “Browser dialog box query”

AuthType Basic

require valid-user

/var/www/.htpasswd是一个.htpasswd文件的典型绝对路径名，用户在要求输入用户名和密码的对话框中会看到字符串Browser dialog box query。

前面.htaccess文件的第二行关闭组功能。第四行指定用户的身份认证类型为Basic，这也是mod_auth模块的默认设置，

最后一行告诉Apache哪些用户可以访问受保护的目录。valid-user条目会授权任何用户(用户名在Apache密码文件中并且输入的密码正确)访问该目录。

只要Apache可以读取其密码文件，该文件可放在系统上的任何地方。把这个文件与.htaccess文件放在同一目录下也是安全的，因为默认情况下，Apache将不会对名字以.ht开头的任何文件的请求进行回复。但是一定不要更改httpd.conf配置文件，以防Apache对名字以.ht开头的文件的请求进行回复。

下面的命令将在工作目录中创建(–c)一个带有Sam条目的.htpasswd文件。省略–c选项可以在现有.htpasswd文件中添加用户或更改密码。

$ htpasswd -c .htpasswd sam

New password:

Re-type new password:

Adding password for user sam

默认的httpd.conf文件包括用于/var/www的AllowOverride None指令。要启用Apache来处理用户认证指令(如读取.htaccess文件)，必须将这个指令更改为AllowOverride AuthConfig或将其删除。

在Apache已配置为可处理.htaccess文件后，当它收到对文件的请求时，必须从所请求的文件向上遍历目录层次结构一直到根目录，查找.htacess文件，以确定它是否可以提供该请求的文件。此搜索可能会影响性能。通常情况下性能下降不太严重，但如果性能很关键，则这个问题将很棘手。

篇4：《3~6岁儿童观学习与发展指南》读后有感

《3~6岁儿童观学习与发展指南》读后有感

阅读了《3~6岁儿童观学习与发展指南》，本《指南》深入贯彻了《幼儿园教育指导纲要》的内容，并进行了归纳。《指南》中将幼儿的学习与发展分为了五个领域，分别是健康、语言、社会、科学、艺术。并给每个方面提出了教育建议，让我在这里学到了很多，这些建议对于我来说受益匪浅，现通过几个方面来说说我学到的。

一、健康

健康包括身体健康和心理健康两个方面，在身体健康中，有一条教育建议是这样的，鼓励幼儿进行跑跳、钻爬、攀登、投掷、拍球等活动，以及跳竹竿、滚铁环等传统体育游戏，发展幼儿的协调性和灵活性。而我们幼儿园有一个课题正是研究体育的，由于这个原因，对于幼儿在各种技能的培养方面也较重视，曾经我们班有个宝贝叫煜煜，煜煜长得胖乎乎的，很可爱，但是却不爱运动，每次早上晨间锻炼的时候，煜煜总是找这样那样的理由不去锻炼，坐在花坛边。我几次过去邀请煜煜一起玩游戏，他都不愿意。但是作为老师的我们，应该尊重每个孩子的发展，注重个体差异，不能横向比较，于是我并没有放弃煜煜，每次都用好玩的游戏区吸引他，最终，煜煜愿意和小朋友一起游戏了，也愿意参加跑跳、钻爬等活动，各方面也得到了发展。

在心理健康方面，需要营造温暖、轻松的心理环境，让幼儿形成安全感和信赖感。小班幼儿刚进园的时候，由于环境陌生，很容易哭闹，这时候教师就应该拿出十分的爱心和耐心去对待孩子，给孩子营造一个温暖的心理环境，让孩子对这个陌生的地方、陌生的人产生好感，多表扬不哭泣的孩子，给予他们鼓励，帮助孩子们尽快适应新环境。例如有些孩子比较内向，不愿与别人交流，我们应该以欣赏的态度去对待幼儿，发现幼儿的优点，将他放大化，鼓励幼儿多与别人交流。

二、语言

语言是交流和思维的工具，幼儿期的语言发展，特别是口语发展的重要时期。应该鼓励幼儿多与别人交流，让他们想说、敢说、喜欢说，并能得到积极回应。而倾听习惯的养成，对于幼儿是很重要的，很多孩子都愿意自己表达，但是却不愿意去倾听别人，在别人讲话时却容易开小差。《指南》中提到了如何养成孩子的倾听习惯，首先教师要做出表率作用，幼儿在和你说话时你要认真倾听，积极做出回应，并且告诉幼儿老师有认真的在听你说话，你是不是也应该认真听老师说话呢。有时候幼儿不愿意倾听，也许是因为幼儿听不懂你在说什么，与幼儿交流时应该用幼儿能听得懂的'语言去交流，这样幼儿就会比较愿意去倾听。对于一些容易开小差的孩子，可以采取多提问的方式，让孩子注意倾听。在《指南》中我学到了很多，这只是语言的一方面，还有很多方面是值得我去学习的。

三、社会

幼儿社会领域的学习与发展过程是幼儿社会性不断完善并奠定健全人格基础的过程，只要包括人际交往与社会适应。有些孩子性格比较内向，不喜欢和别的小朋友交往，回家还会告诉父母，小朋友不喜欢我，欺负我。对于这样的孩子，《指南》中也提到了解决的策略，可以与家长沟通，让家长多带着孩子去朋友家或者亲戚家做客，鼓励幼儿多与别人交流。让孩子多与其他小朋友一起玩耍，同龄孩子在一起比较容易接触，容易相处，多和小朋友一起游戏，也可以让孩子邀请自己的好朋友来家里玩，多交一些朋友，也会变得开朗外向起来。幼儿园也应该多提供一些自由交往和游戏的机会，鼓励幼儿自主选择玩伴进行游戏，并通过角色游戏，让孩子们主动交流与交往。

四、科学

幼儿的科学学习是幼儿在解决实际问题的过程中发现和理解事物本质和事物间关系的过程，主要包括科学探究和数学认知。很多幼儿在探究科学时都不愿意去动脑筋，总是依赖于老师，到自己操作时就是一句老师我不会。面对这样的现象，《指南》中也提到了该如何去解决，应该支持和鼓励幼儿在探究的过程中积极动手动脑寻找答案或解决问题。例如某个现象，教师应该提出问题，让孩子们自己去寻找答案，而这个问题要让孩子们感兴趣，并且愿意大胆的去猜测，而教师应该尊重孩子们的猜测，就算是错误的，也应该让孩子自己去证实自己的想法是否正确，寻找答案的过程可以让孩子学到很多东西，也可以锻炼孩子独立思考的能力。在孩子在寻找的道路上遇到困难或者方向错误时，教师应该进行适量的引导，而不是急于将答案告诉幼儿，自己寻找出来的答案会远比你告诉他来的有意义的多。

五、艺术

艺术是人类感受美、表现美和创造美的重要形式，也是表达自己对周围世界的认识和情绪态度的特有方式。在艺术创作时，应该尊重幼儿自发的表现和创造，并给予适当的指导。其实每个孩子都是一个小小设计师，孩子的创造力和想象力远远超过了老师的想象，应该尊重孩子的天性。给幼儿提供丰富的材料，让幼儿自由选择，用适宜自己的表现方式去模仿和创作，不应给予太多的要求。对于幼儿创造出来的作品，教师应给予相对的肯定，鼓励孩子。对于孩子的不足，可以婉转的告诉幼儿，如果可以这样，那就更完美了，而不是否定幼儿的作品。

《指南》中很多的教学建议对于我的启发很大很大，和孩子相处也是一门很深的学问，我要学习的东西还有很多很多，在教师的这条路上，我会不断的学习，努力做好《指南》中的建议，争取做一个好老师。

篇5：专家谈：从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，现为迈克菲首席技术官。

George Kurtz

篇6：RatProxy：Google提供的开源Web应用安全审核工具

Google宣布将它的一款内部安全工具“ratproxy”开放源代码，Ratproxy用于被动地审核Web应用的安全性：

Ratproxy可以分析很多问题，比如存在威胁的跨站脚本包含、对伪造的跨站请求防范不足、缓存问题，潜在的XSS、可能不安全的跨站代码包含策略、信息泄露，不一而足。

作为一款被动工具，Ratproxy会监视浏览器与Web应用之间的交互。其文档中宣称，这样的工作方式使它比传统方法具备以下优势：

不会破坏现有Web应用

低投入，高产出

可以保留用户与Web应用交互的控制流

在脚本行为中的WYSIWYG（所见即所得）数据

简化了过程整合

与其他安全审核工具相比（如WebScarab、Paros、Burp、ProxMon和Pantera），Ratproxy的创建者Michal Zalewski说：

Ratproxy明确地关注当代Web 2.0应用中优先级最高的问题，为它们提供简明的报告，给予用户充分的自由，以可重复的方式来完成这些工作，

管理资料

用户不会再被大量原始的HTTP流量数据淹没，而且这个工具远不仅仅是一个人工干预应用程序的框架。

Ratproxy (1.50 beta) （164 Kb）可用于Linux、FreeBSD、MacOS X和Windows（Cygwin）环境。

查看英文原文：Google Releases Open Source Web Application Security Assessment Tool

来自：www.infoq.com/cn/news//07/ratproxy

相关阅读：RatProxy：Google提供的网站漏洞侦测工具

篇7：入侵我不怕 Outpost防火墙应用技巧攻略WEB安全

常在河边走，哪有不湿鞋，经常上网的朋友大都有过被 、病毒攻击的经历，于是自己的一些诸如邮箱账号、QQ密码、论坛账号等重要数据就存在被窃取的危险。而在更多的情况下，则往往会发生系统不断重启、黑屏甚至系统瘫痪等现象。

为了防止这些恶意攻击，一款好用的防火墙自然必不可少，比如大家所熟知的“天网防火墙”、“瑞星个人防火墙”、“诺顿防火墙”等。不过今天我要给大家介绍一款小巧易用而功能又很强大的工具，它便是“Outpost Firewall”。它除了能够预防来自Cookies、广告、电子邮件病毒、后门木马、间谍软件、广告软件和其他 Internet潜在的危险外，还可以利用插件去让功能得到进一步拓展，使该款产品更加超值。

本地高速下载Outpost Firewall

一、Outpost Firewall的基本应用方法

将该防火墙安装后，软件会要求进行“自动配置个人防火墙规则”，一般选择“自动配置防火墙规则”即可；而在下一步的“网络配置”中，一般可以选择“使用自动配置规则”，当完成这些后，必须重新启动操作系统。

步骤1 重启系统后，它就开始发挥作用了，在启动过程中若某个程序需要连接网络，那么便会弹出有关为该程序创建规则的对话框。在该对话框中，我们可以从对话框的标题名称或者页面上的程序名称，了解到该程序到底为何种程序。

步骤2 如果该程序值得信任，用户也对它非常了解，那么只要点选“允许这个应用程序的所有动作”选项，就可以让该程序顺利通过防火墙的验证；若是用户得知该程序具有一定的危害性，那么不妨点选“挡截这个应用程序的所有动作”选项，这种该程序就不会再与网络发生连接关系。

步骤3 若是用户对该程序不甚了解，那么不妨单击“本次允许”或“本次挡截”按钮，去临时允许或拦截该程序的联网动作。当了解了该程序的具体属性及作用后，便可为其设置永久性的动作。当设置完成后，单击“确定”按钮即可。

二、更改防火墙运行模式

之所以会弹出上述创建规则对话框，这是因为“Outpost Firewall”默认的运行模式是“规则向导模式”。如果你对频频弹出的创建规则对话框感到厌烦，那么不妨双击系统中的防火墙图标打开其主界面，依次打开主菜单“选项→运行模式”选项命令，在弹出的对话框中便可更改防火墙的运行模式。

其中单击“禁用模式”选项，便可让防火墙失去作用，当前系统便不会受到防火墙的任何防护；单击“允许大部分通讯模式”选项，那些没有被禁止的通讯都可允许出入本机系统；单击“禁止大部分通讯模式”选项，则可让所有没有被允许的通讯禁止出入本机系统；而单击“停止通讯模式”，就可以使本机与网络的连接完全断开，

三、为程序“量身定做”通讯方式

在选择防火墙的运行模式时，我们发现“允许的通讯”和“禁止的通讯”这些表述，那么到底在哪里才能设定这些“允许的通讯”和“禁止的通讯”呢？为了便于说明，我们以禁止和允许QQ应用程序进行通讯为例。

1、禁止QQ通讯

步骤1 在开启的主界面中，依次打开“选项→应用程序”选项命令，在出现的对话框中选中“禁止的应用程序”选项。

步骤2 单击“添加”按钮，在打开的窗口中选择QQ主程序，即可将QQ程序添加到“禁止的应用程序”中，然后单击“确定”按钮。此时若再次登录QQ，便会发现QQ已经无法登录了。

2、允许QQ通讯

步骤1 若打算让QQ登录成功“复活”，那么可在“禁止的应用程序”区域中选中QQ程序，而后单击“删除”按钮，就可以将QQ程序从“禁止的应用程序”移除。

步骤2 选中“部分允许的应用程序”选项，单击“添加”按钮，选择QQ主程序进行添加，在添加时会弹出一个规则对话框，只要单击“确定”按钮，便可将QQ程序添入其中。

当再次运行QQ程序时，便会弹出一个“为QQ.EXE创建规则”对话框。如果你只打算暂时运行QQ，那么可单击“本次允许”按钮，这样便可临时让QQ登录。当QQ成功登录后，我们会发现QQ的程序名称仍保留在“部分允许的应用程序”区域中。

如果在创建规则时，直接点选“允许这个应用程序的所有动作”选项，单击“确定”按钮，那么在“部分允许的应用程序”中就不会再发现QQ的主程序名称，此时它会被移至“信任的应用程序”区域中。

而用户若是需要一直应用某个程序去进行通讯，那么不妨选择“信任的应用程序”选项，单击“添加”按钮直接将该程序加入其中，这样便不会再弹出要求为该程序创建规则的对话框了。

以上是“Outpost Firewall”的基本应用方法，当学会这些方法后，新手朋友们就可以借助它为自己的电脑构筑一道防火墙了。

篇8：使用PHP 构建的Web 应用如何避免XSS 攻击脚本安全

使用PHP 构建的Web 应用如何避免XSS 攻击

Web 2.0 的发展为网络用户的互动提供了更多机会，用户通过在论坛发表评论，或是在博客发表留言都可能有意或无意输入一些破坏性的内容，从而造成网页不能正常显示，影响其它用户的使用。XSS 全称为Cross Site Scripting，因为CSS 已经用作样式表的简称，故称为XSS。XSS 是一种常见的网站攻击的方法。其原理是通过在网页的输入框输入一些恶意的内容，通常是JavaScript. 脚本片段，而这些恶意输入在提交之后并重新读回到客户端时，浏览器会解释执行这些恶意的脚本内容，从而影响网页的正常显示。

本文首先简单介绍开发测试人员如何对Web 应用进行XSS 漏洞测试，如何借助工具绕过客户端JavaScript. 校验输入恶意数据；然后针对使用PHP 语言构建的Web 站点，从在输出端对动态内容进行编码、以及在服务器端对输入进行检测两方面介绍如何避免恶意的XSS 攻击。

对Web 应用进行XSS 漏洞测试

测试路径

对WEB 应用进行XSS 漏洞测试，不能仅仅局限于在WEB 页面输入XSS 攻击字段，然后提交。绕过JavaScript. 的检测，输入XSS 脚本，通常被测试人员忽略。下图为XSS 恶意输入绕过JavaScript. 检测的攻击路径。

图1. XSS 攻击测试路径– 绕过JavaScript 校验

常见的XSS 输入

XSS 输入通常包含JavaScript. 脚本，如弹出恶意警告框：

XSS 输入也可能是HTML 代码段，譬如：

网页不停地刷新 

嵌入其它网站的链接

XSS (Cross Site Scripting) Cheat Sheet维护了一份常见的XSS 攻击脚本列表，可用来作为检测WEB 应用是否存在XSS 漏洞的测试用例输入。初次接触XSS 攻击的开发人员可能会对列表提供的一些XSS 输入不是很理解，本文第二部分将会针对不同代码上下文的XSS 输入作进一步的解释。

测试工具

很多工具可以在浏览器发送Get/Post 请求前将其截取，攻击者可以修改请求中的数据，从而绕过JavaScript. 的检验将恶意数据注入服务器。以下是一些常用的截取HTTP 请求的工具列表。

Paros proxy  (www.parosproxy.org)

Fiddler  (www.fiddlertool.com/fiddler)

Burp proxy  (www.portswigger.net/proxy/)

TamperIE  (www.bayden.com/dl/TamperIESetup.exe)

笔者曾经使用TamperIE 对WEB 应用进行安全性测试。TamperIE 小巧易用，能够截取IE 浏览器发送的Get/Post 请求，甚至能绕过SSL 加密。不过TamperIE + IE7 工作不稳定。IE7 提供了对IPV6 的支持，如果你并不计划测试你的Web 应用对IPV6 的支持，建议还是使用TamperIE + IE6 的组合。

如图2所示: TamperIE 绕过客户端浏览器JavaScript. 的校验，在POST 请求提交时将其截取，用户可以任意修改表单输入项name 和message 的值，譬如将message 的值修改为 “”，然后点击”Send altered data” 按钮，将修改后的恶意数据发送给Web 服务器。

图2. 使用TamperIE 截取Post 请求

在输出端对动态内容进行编码

对一个Web 应用而言，其动态内容可能来源于用户输入、后台数据库、硬件状态改变或是网络信息等。动态内容特别是来自用户输入的动态内容很有可能包含恶意数据，从而影响网页的正常显示或是执行恶意脚本。将动态内容安全地显示在浏览器端与动态内容所处的上下文背景有关，譬如动态内容处在HTML 正文、表单元素的属性、或是JavaScript. 代码段中。对于一个基于PHP 语言的Web 应用，当执行 “echo”、“print”、“printf”、“

使用PHP 的htmlspecialchars 显示HTML 特殊字符

从上文列举的XSS 恶意输入可以看到，这些输入中包含了一些特殊的HTML 字符如”<“、”>“。当传送到客户端浏览器显示时，浏览器会解释执行这些HTML 或JavaScript. 代码而不是直接显示这些字符串。< >& “ 等字符在HTML语言中有特殊含义，对于用户输入的特殊字符，如何直接显示在网页中而不是被浏览器当作特殊字符进行解析?

HTML字符实体由& 符号、实体名字或者# 加上实体编号、分号三部分组成。以下为HTML 中一些特殊字符的编码。有的字符实体只有实体编号，没有对应的实体名字，譬如单引号。

表1. 一些HTML 特殊字符的实体编码

显示实体名字实体编号<<>>&&&“”“‘N/A'

PHP 提供了 htmlspecialchars() 函数可以将HTML 特殊字符转化成在网页上显示的字符实体编码。这样即使用户输入了各种HTML 标记，在读回到浏览器时，会直接显示这些HTML 标记，而不是解释执行。htmlspecialchars() 函数可以将以下五种HTML 特殊字符转成字符实体编码：

& 转成&

“ 转成”

< 转成<

>转成>

‘ 转成'

当直接调用 htmlspecialchars($str) 时, & “ < >被转义。

当设置ENT_QUOTES 标记时, 即调用 htmlspecialchars($str, ENT_QUOTES) 时，单引号也被转义。

当设置ENT_NOQUOTES 标记时，单引号和双引号都不会被转义。即调用 htmlspecialchars($str, ENT_NOQUOTES) 时，只有& < >被转义。

不同背景下的动态内容的XSS 攻击及解决方案

XSS 攻击输入与动态内容所处的代码背景相关，譬如动态内容为表单元素属性的值、位于HTML 正文、或是Javascript. 代码段中等等。

HTML标记的属性为动态内容

Web 应用中，”input“、”style“、”color“ 等HTML 标记的属性都可能为动态内容，其中”input“ 标记的”value“ 属性通常为动态内容。

例子1

value=”

攻击XSS输入

Hello“>

将动态内容替换

将 $msg 替换为恶意XSS 输入:

value=”Hello“>”>

例子2

maxlength=8 value=

攻击XSS 输入

Hello nmouseover=evil_script()

将动态内容替换

将 $msg 替换为恶意XSS 输入:

maxlength=8 value=Hello nmouseover=evil_script()>

分析

从例子1 可以看到其XSS攻击输入中包含了HTML 特殊字符< >“

从例子2 可以看到其XSS 攻击输入中没有包含上节中提到的五种HTML 字符，但是”value“属性值没有使用双引号包围，

解决方案

调用 htmlspecialchars($str, ENT_QUOTES) 将以下5 种HTML 特殊字符< >&‘ “ 转义；同时使属性值被双引号包围。譬如：

maxlength=8 value=”

注意事项

将input 的value 进行转义，必须考虑显示和存储数据的一致性问题，即显示在浏览器端和存储在服务器端后台的数据可能因为转义而变得不一致。譬如存储在服务器端的后台原始数据包含了以上5 种特殊字符，但是没有转义，为了防止XSS 攻击，在浏览器端输出时对HTML 特殊字符进行了转义：

1. 当再度将表单提交时，存储的内容将会变成转义后的值。

2. 当使用JavaScript. 操作表单元素，需要使用到表单元素的值时，必须考虑到值可能已经被转义。

HTML文本为动态内容

例子

欢迎：

攻击XSS输入

将动态内容替换

将 $welcome_msg 替换为恶意XSS 输入:

欢迎：

分析

在HTML 正文背景下，< >字符会引入HTML 标记，& 可能会认为字符实体编码的开始，所以需要将< >& 转义

解决方案

为简洁起见，直接使用 htmlspecialchars() 将5 种HTML 特殊字符转义，如：

欢迎：

URL的值为动态内容

Script/Style/Img/ActiveX/Applet/Frameset… 等标记的src 或href 属性如果为动态内容，必须确保这些URL 没有指向恶意链接。

例子1

的UTF-7 编码为：+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-

如果 +ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4- 作为动态内容位于网页的顶端并传送到浏览器端，IE 会认为此网页是UTF-7 编码，从而使网页不能正常显示。

解决方案

显式定义网页的字符集编码，譬如

动态内容为JavaScript事件处理函数的参数

JavaScript. 事件处理函数如onClick/onLoad/onError/onMouseOver/ 的参数可能包含动态内容。

例子

攻击XSS输入

foo“);evil_script(”

将动态内容替换

HTML 解析器会先于JavaScript. 解析器解析网页，将 $target_url 替换为恶意XSS 输入:

动态内容位于JavaScript 代码段中

例子

攻击XSS输入1

Hello'; evil_script(); //

将动态内容替换

将 $welcome_msg 替换为恶意XSS 输入:

攻击XSS输入2

Hello

分析

如上文所示，在JavaScript. 背景中使用动态内容需要非常谨慎。一般情况下，尽量避免或减少在Javascript. 的背景下使用动态内容，如果必须使用动态内容，在开发或代码审计时必须考虑这些动态内容可能的取值，是否会导致XSS 攻击。

建立PHP库函数校验输入

Web 开发人员必须了解，仅仅在客户端使用JavaScript. 函数对非法输入进行检测过滤对于构建安全的WEB 应用是不够的。如上文所述，攻击者可以轻易地借助工具绕过JavaScript. 校验甚至SSL 加密输入恶意数据。在输出端对动态内容进行编码也只能起到一种双重保护的作用，更重要的应该在服务器端对输入进行校验。PHP 提供了strpos()、strstr()、preg_match() 等函数可用于检测非法字符和字符串；preg_replace() 函数可用于替换非法字符串。OWASP PHP Filters开源项目提供了一些PHP 库函数用于过滤非法输入可作为参考。一些常见的检测和过滤包括：

输入是否仅仅包含合法的字符；

输入如果为数字，数字是否在指定的范围；

输入字符串是否超过最大长度限制；

输入是否符合特殊的格式要求，譬如email 地址、IP 地址；

不同的输入框在逻辑上存在的耦合和限制的关系；

除去输入首尾的空格；

总结

Web 应用的安全性是一个很重要、覆盖范围很广泛的主题。为了防止常见的XSS 的攻击，Web 开发人员必须明白不能仅仅只在客户端使用JavaScript. 对输入进行检测、过滤；同时还应建立服务器端的输入校验、输出编码库函数；在服务器端检测、过滤输入；根据动态内容所处的背景将特殊字符进行编码后再传送给浏览器端显示。​

篇9：输入验证C避免50%（只是经验值）以上的应用安全攻击WEB安全

俗话说病从口入，可以说绝大多数的应用安全问题的源头都是由输入的入口引发，但是输入入口安全检测不能解决所有的潜在安全问题，原因很简单，那就是接收输入的数据时，接收者并不知道此数据用来做什么，涉及的业务逻辑是什么，所以无法在输入入口处进行完备而妥善的安全检测与处理，但是，还是要强调一下这个“但是”，我们不能因为此处不能解决所有的问题而放弃它忽略它，本文将告诉你：做好完善合理的“输入验证”，可以解决50%（只是经验值，后文不再解释）以上的企业应用安全攻击。

概念解释：

1. 输入

广义的“输入”是相对于发送端与接收端的一个相对的概念，对于基于HTTP的web应用程序，那就是来自于浏览器这一端发往HTTP服务端请求数据包皆为输入，以此类推，请求端的所有数据对于服务端来说皆为数据输入。

2. 输入验证

就是在服务端（强调一下：是服务端，而不是客户端）依据业务逻辑的需要对来自于客户端数据进行合法性校验的过程。

我们先从两个大家最熟悉的安全攻击开始来看看它们与输入的关系是什么。

例1，XSS（跨站脚本攻击），大家可以在firefox上试一下这个测试链接：

www.testfire.net/search.aspx?txtSearch=alert%2812345%29<%2Fscript>

这就是一个典型的反射式跨站脚本攻击，它的过程是这样的：字符串alert%2812345%29<%2Fscript.>通过HTTP的请求传送到服务端，服务端经过自己的业务逻辑处理后返回到浏览器这一端，由于返回后未做正确的编码，以至于在客户端被浏览器执行。

例2，SQL Injection(SQL注入攻击），大家也可以在firefox上测试一下这个链接：

www.testfire.net/bank/login.aspx?uid=admin%27+or+%271%27%3D%271&passw=admin%27+or+%271%27%3D%271&btnSubmit=Login

这是一个典型的SQL注入问题，它的过程是这样的，字符串admin%27+or+%271%27%3D%271的原型是：admin’ or ’1′=’1，这显然是通过猜测应用程序后台的实现方式，假设后台程序实现人员通过把用户的输入拼装到SQL查询语句上进行SQL查询的，以至于轻易的被 注入自编的SQL语句，骗过登录验证逻辑而成功以管理员身份登录，

这两个例子当中，输入项有许多，我们只关注txtSearch/uid/passw这三个输入点，它们是这两个问题的输入源，对它进行输入验证是否有意义呢？ 当然有。假如我们的业务逻辑上只要求txtSearch/uid/passw这个输入点长度只需要15，数据类型只需要数字与英文字母即可满足产品的设计需求，那么我们则可以这么做：

1) 服务端获取txtSearch/uid/passw的值2）确认它的长度是否超过153）它的值是否只包含字母与数字

后台实现上，只有以上条件完全满足，再进行进一步业务逻辑处理，否则以友好的方式告知客户端输入非法。当然，为了更好的用户体验，可以在客户端（假如是HTTP web应用程序）用JS实时的动态提示用户本处可以接受的合法输入是什么。这么做的好处是什么？

1）对于第一个例子，如果我们因为疏忽或者某些未预料原因而导致XSS问题，由于你的限制足够苛刻，以至于即便有XSS问题， 也难以对其进行很好的利用，因为有长度限制，也有字符集的限制。

2）对于第二个例子，如果我们真的因为实现上的疏忽而留下了SQL注入的安全问题，也会因为字符集、字符串长度的限制而让 无法进一步利用它做更多的坏事儿。

以上只是抛砖引玉，象目录遍历、文件上传、缓冲区溢出等等诸多应用安全问题，均可通过合理的正确的输入验证方式减少、降低甚至避免安全攻击的发生。

关于输入验证，个人将其分为两大类，一类是普通的字符串输入，绝大多数是属于这一类；另一类是支持富文本的输入，比如文档编辑、允许用户输入简单标签的输入点。对于第二类，可以使用OWASP提供的AntiSamy (www.owasp.org/index.php/Category:OWASP_AntiSamy_Project)框架来辅助解决。

最后强调一下就是：我并没有想表达做好输入验证就可以解决所有的安全问题，它的重要程度、利害关系及意义通过以上的描述，我想已经表达清楚了。做好输入验证的座右铭是：永远不要相信来自于客户端的输入，这里的输入不仅仅是显式的用户直接输入,同时也包括隐式的协议数据包部分。

如果有兴趣，我将在下篇文章中给大家展示《利用浏览器渲染(HTML/JS/CSS)原理从根本上解决XSS问题》系列博文，我相信在彻底解决XSS问题的方案上有许多地方与你想的不一样。

说明：www.testfire.net是一个实验平台，它不是一个真正的应用，大家可以在上面做一个安全漏洞的实验而不会触及法律。

​

《协和医事》读后有感

孔乙己课文读后有感

《平凡的世界》读后有感

《百万英镑》读后有感

西游记课外书读后有感

《Web应用安全权威指南》读后有感.doc

将本文的Word文档下载到电脑，方便收藏和打印

推荐度：

点击下载文档