web安全csdn

Ⅳ 白帽子讲Web安全的前言

在2010年年中的时候，博文视点的张春雨先生找到我，希望我可以写一本关于云计算安全的书。当时云计算的概念正如日中天，但市面上关于云计算安全应该怎么做却缺乏足够的资料。我由于工作的关系接触这方面比较多，但考虑到云计算的未来尚未清晰，以及其他的种种原因，婉拒了张春雨先生的要求，转而决定写一本关于Web安全的书。 我对安全的兴趣起源于中学时期。当时在盗版市场买到了一本没有书号的黑客手册，其中coolfire 的黑客教程令我印象深刻。此后在有限的能接触到互联网的机会里，我总会想方设法地寻找一些黑客教程，并以实践其中记载的方法为乐。
在2000年的时候，我进入了西安交通大学学习。在大学期间，最大的收获，是学校的计算机实验室平时会对学生开放。当时上网的资费仍然较贵，父母给我的生活费里，除了留下必要的生活所需费用之外，几乎全部投入在这里。也是在学校的计算机实验室里，让我迅速在这个领域中成长起来。
大学期间，在父母的资助下，我拥有了自己的第一台个人电脑，这加快了我成长的步伐。与此同时，我和一些互联网上志同道合的朋友，一起建立了一个技术型的安全组织，名字来源于我当时最喜爱的一部动漫：“幻影旅团”。历经十余载，“幻影”由于种种原因未能得以延续，但它却曾以论坛的形式培养出了当今安全行业中非常多的顶尖人才。这也是我在这短短二十余载人生中的最大成就与自豪。
得益于互联网的开放性，以及我亲手缔造的良好技术交流氛围，我几乎见证了全部互联网安全技术的发展过程。在前5年，我投入了大量精力研究渗透测试技术、缓冲区溢出技术、网络攻击技术等；而在后5年，出于工作需要，我把主要精力放在了对Web安全的研究上。 发生这种专业方向的转变，是因为在2005年，我在一位挚友的推荐下，加入了阿里巴巴。加入的过程颇具传奇色彩，在面试的过程中主管要求我展示自己的能力，于是我远程关闭了阿里巴巴内网上游运营商的一台路由设备，导致阿里巴巴内部网络中断。事后主管立即要求与运营商重新签订可用性协议。
大学时期的兴趣爱好，居然可以变成一份正经的职业（当时很多大学都尚未开设网络安全的课程与专业），这使得我的父母很震惊，同时也更坚定了我自己以此作为事业的想法。
在阿里巴巴我很快就崭露头角，曾经在内网中通过网络嗅探捕获到了开发总监的邮箱密码；也曾经在压力测试中一瞬间瘫痪了公司的网络；还有好几次，成功获取到了域控服务器的权限，从而可以以管理员的身份进入任何一位员工的电脑。
但这些工作成果，都远远比不上那厚厚的一摞网站安全评估报告让我更有成就感，因为我知道，网站上的每一个漏洞，都在影响着成千上万的用户。能够为百万、千万的互联网用户服务，让我倍感自豪。当时，Web正在逐渐成为互联网的核心，Web安全技术也正在兴起，于是我义无返顾地投入到对Web安全的研究中。
我于2007年以23岁之龄成为了阿里巴巴集团最年轻的技术专家。虽未有官方统计，但可能也是全集团里最年轻的高级技术专家，我于2010年获此殊荣。在阿里巴巴，我有幸见证了安全部门从无到有的建设过程。同时由于淘宝、支付宝草创，尚未建立自己的安全团队，因此我有幸参与了淘宝、支付宝的安全建设，为他们奠定了安全开发框架、安全开发流程的基础。 当时，我隐隐地感觉到了互联网公司安全，与传统的网络安全、信息安全技术的区别。就如同开发者会遇到的挑战一样，有很多问题，不放到一个海量用户的环境下，是难以暴露出来的。由于量变引起质变，所以管理10台服务器，和管理1万台服务器的方法肯定会有所区别；同样的，评估10名工程师的代码安全，和评估1000名工程师的代码安全，方法肯定也要有所不同。
互联网公司安全还有一些鲜明的特色，比如注重用户体验、注重性能、注重产品发布时间，因此传统的安全方案在这样的环境下可能完全行不通。这对安全工作提出了更高的要求和更大的挑战。
这些问题，使我感觉到，互联网公司安全可能会成为一门新的学科，或者说应该把安全技术变得更加工业化。可是我在书店中，却发现安全类目的书，要么是极为学术化的（一般人看不懂）教科书，要么就是极为娱乐化的（比如一些“黑客工具说明书”类型的书）说明书。极少数能够深入剖析安全技术原理的书，以我的经验看来，在工业化的环境中也会存在各种各样的问题。
这些问题，也就促使我萌发了一种写一本自己的书，分享多年来工作心得的想法。它将是一本阐述安全技术在企业级应用中实践的书，是一本大型互联网公司的工程师能够真正用得上的安全参考书。因此张春雨先生一提到邀请我写书的想法时，我没有做过多的思考，就答应了。
Web是互联网的核心，是未来云计算和移动互联网的最佳载体，因此Web安全也是互联网公司安全业务中最重要的组成部分。我近年来的研究重心也在于此，因此将选题范围定在了Web安全。但其实本书的很多思路并不局限于Web安全，而是可以放宽到整个互联网安全的方方面面之中。
掌握了以正确的思路去看待安全问题，在解决它们时，都将无往而不利。我在2007年的时候，意识到了掌握这种正确思维方式的重要性，因此我告知好友：安全工程师的核心竞争力不在于他能拥有多少个0day，掌握多少种安全技术，而是在于他对安全理解的深度，以及由此引申的看待安全问题的角度和高度。我是如此想的，也是如此做的。
因此在本书中，我认为最可贵的不是那一个个工业化的解决方案，而是在解决这些问题时，背后的思考过程。我们不是要做一个能够解决问题的方案，而是要做一个能够“漂亮地”解决问题的方案。这是每一名优秀的安全工程师所应有的追求。 然而在当今的互联网行业中，对安全的重视程度普遍不高。有统计显示，互联网公司对安全的投入不足收入的百分之一。
在2011年岁末之际，中国互联网突然卷入了一场有史以来最大的安全危机。12月21日，国内最大的开发者社区CSDN被黑客在互联网上公布了600万注册用户的数据。更糟糕的是，CSDN在数据库中明文保存了用户的密码。接下来如同一场盛大的交响乐，黑客随后陆续公布了网易、人人、天涯、猫扑、多玩等多家大型网站的数据库，一时间风声鹤唳，草木皆兵。
这些数据其实在黑客的地下世界中已经辗转流传了多年，牵扯到了一条巨大的黑色产业链。这次的偶然事件使之浮出水面，公之于众，也让用户清醒地认识到中国互联网的安全现状有多么糟糕。
以往类似的事件我都会在博客上说点什么，但这次我保持了沉默。因为一来知道此种状况已经多年，网站只是在为以前的不作为而买单；二来要解决“拖库”的问题，其实是要解决整个互联网公司的安全问题，远非保证一个数据库的安全这么简单。这不是通过一段文字、一篇文章就能够讲清楚的。但我想最好的答案，可以在本书中找到。
经历这场危机之后，希望整个中国互联网，在安全问题的认识上，能够有一个新的高度。那这场危机也就物有所值，或许还能借此契机成就中国互联网的一场安全启蒙运动。
这是我的第一本书，也是我坚持自己一个人写完的书，因此可以在书中尽情地阐述自己的安全世界观，且对书中的任何错漏之处以及不成熟的观点都没有可以推卸责任的借口。
由于工作繁忙，写此书只能利用业余时间，交稿时间多次推迟，深感写书的不易。但最终能成书，则有赖于各位亲朋的支持，以及编辑的鼓励，在此深表感谢。本书中很多地方未能写得更为深入细致，实乃精力有限所致，尚请多多包涵。 在安全圈子里，素有“白帽”、“黑帽”一说。
黑帽子是指那些造成破坏的黑客，而白帽子则是研究安全，但不造成破坏的黑客。白帽子均以建设更安全的互联网为己任。
我于2008年开始在国内互联网行业中倡导白帽子的理念，并联合了一些主要互联网公司的安全工程师，建立了白帽子社区，旨在交流工作中遇到的各种问题，以及经验心得。
本书名为《白帽子讲Web安全》，即是站在白帽子的视角，讲述Web安全的方方面面。虽然也剖析攻击原理，但更重要的是如何防范这些问题。同时也希望“白帽子”这一理念，能够更加的广为人知，为中国互联网所接受。 全书分为4大篇共18章，读者可以通过浏览目录以进一步了解各篇章的内容。在有的章节末尾，还附上了笔者曾经写过的一些博客文章，可以作为延伸阅读以及本书正文的补充。
第一篇 我的安全世界观是全书的纲领。在此篇中先回顾了安全的历史，然后阐述了笔者对安全的看法与态度，并提出了一些思考问题的方式以及做事的方法。理解了本篇，就能明白全书中所涉及的解决方案在抉择时的取舍。
第二篇 客户端脚本安全就当前比较流行的客户端脚本攻击进行了深入阐述。当网站的安全做到一定程度后，黑客可能难以再找到类似注入攻击、脚本执行等高风险的漏洞，从而可能将注意力转移到客户端脚本攻击上。
客户端脚本安全与浏览器的特性息息相关，因此对浏览器的深入理解将有助于做好客户端脚本安全的解决方案。
如果读者所要解决的问题比较严峻，比如网站的安全是从零开始，则建议跳过此篇，先阅读下一篇“服务器端应用安全”，解决优先级更高的安全问题。
第三篇 服务器端应用安全就常见的服务器端应用安全问题进行了阐述。这些问题往往能引起非常严重的后果，在网站的安全建设之初需要优先解决这些问题，避免留下任何隐患。
第四篇 互联网公司安全运营提出了一个大安全运营的思想。安全是一个持续的过程，最终仍然要由安全工程师来保证结果。
在本篇中，首先就互联网业务安全问题进行了一些讨论，这些问题对于互联网公司来说有时候会比漏洞更为重要。
在接下来的两章中，首先阐述了安全开发流程的实施过程，以及笔者积累的一些经验。然后谈到了公司安全团队的职责，以及如何建立一个健康完善的安全体系。
本书也可以当做一本安全参考书，读者在遇到问题时，可以挑选任何所需要的章节进行阅读。 感谢我的妻子，她的支持是对我最大的鼓励。本书最后的成书时日，是陪伴在她的病床边完成的，我将铭记一生。
感谢我的父母，是他们养育了我，并一直在背后默默地支持我的事业，使我最终能有机会在这里写下这些话。
感谢我的公司阿里巴巴集团，它营造了良好的技术与实践氛围，使我能够有今天的积累。同时也感谢在工作中一直给予我帮助和鼓励的同事、上司，他们包括但不限于：魏兴国、汤城、刘志生、侯欣杰、林松英、聂万全、谢雄钦、徐敏、刘坤、李泽洋、肖力、叶怡恺。
感谢季昕华先生为本书作序，他一直是所有安全工作者的楷模与学习的对象。
也感谢博文视点的张春雨先生以及他的团队，是他们的努力使本书最终能与广大读者见面。他们的专业意见给了我很多的帮助。
最后特别感谢我的同事周拓，他对本书提出了很多有建设性的意见。
吴翰清
2012年1月于杭州

Ⅳ java工作流引擎中，哪个在市面上用得最多

一起来看看java快速开发框架工作流引擎快速开发平台。 希望您能从中找到适合您自己的流程引擎。

Activiti是由jBPM 的创建Tom Baeyen离JBoss之后建立的项目，构建在开发 jBPM 版本1到4时积累的多年经验的基础之上，旨在创建下一代的 BPM 解决方案。文档丰富，csdn有相应专栏，并且国人贡献了一本《activiti实战》详细地讲解了基于activiti的开发内容，网上教程资源丰富。Activiti上手比较快，界面也比较简洁、直观，学习周期相对较短。

官方提供webapp war包，部署在Tomcat下可快速操作和了解activiti，esclipse提供支持activiti项目的ide插件，总的来说环境支持良好。

代码量大，核心代码改动难度较大，但提供了完整的技术文档，架构良好，网上开发文档较多，一定上降低了二次开发的难度。

支持，用户体验好，但是流程设计器是英文版，还需要汉化。

支持多种表单：动态表单，外置表单，普通表单，但表单设计未集成，需要自己集成表单设计。

支持绝大部分工作流功能，符合中国国情的审批流程需要在此基础上进行开发。

JBPM（Java Business Process Management）：JAVA业务流程管理，是一个可扩展、灵活、开源的流程引擎， 它可以运行在独立的服务器上或者嵌入任何Java应用中。

1、jBPM3是一个完整的工作流系统实现，面向开发人员，目的在于简化对组织核心流程进行支撑的软件创建，不支持标准。

2、jBPM4引入PVM，使其拥有更强大的扩展性，同时增加BPMS特性，这些特性包括了对BPMN的支持、面向业务人员的Web建模器和简单统计分析功能的加入。

3、jBPM5基于原先的Drools Flow，支持BPMN，通过与Drools的合并支持BAM，通过内容仓库增加对流程可视化的支持。由于放弃了jBPM4的PVM，引擎的可扩展性受到损害，并且不再支持jPDL。

XJR快速开发平台可视化开发，高效快速，开发成本低。兼容强，支持多种数据库，基于B/S架构，纯浏览器应用，只需要拖拽组件，拼接流程，就能实现各层的审批。面向服务接口设计，容易整合企业现有的资源。前后端分离设计，采用shiro权限验证，通过简单配置就可以实现功能权限和数据权限。开源级代码，二次扩展强。

XJR快速开发平台技术选型

使用目前流行的多种web技术，包括springboot， JPA，Druid， Activiti，Lombok，swagger，poi，WebSocket，Jquery，BootStrap， maven，Jenkins 等等，支持多种数据库MySQL, Oracle, sqlserver等。 分层设计：使用分层设计，分为，service，Controller，view层，层次清楚，低耦合，高内聚。 安全考虑：严格遵循了web安全的规范，前后台双重验证，参数编码传输，密码md5加密存储，shiro权限验证，从根本上避免了SQL注入，XSS攻击，CSRF攻击等常见的web攻击手段。

模块功能

功能模块：开发向导、代码 生成器，商业智能、工作流、报表管理、移动端开发、作业计划、多语言、数据源管理、企业微信、钉钉、消息管理，菜单 管理，用户管理，机构管理，角色管理，区域管理，字典管理，日志查询等基础模块。

Ⅵ 谁来帮帮我！

下面是PHP5中PHP.INI中文详细配置，你试试

;;;;;;;;;;;;;;
;; Apache ;;
;;;;;;;;;;;;;;
[Apache]
; 仅在将PHP作为Apache模块时才有效。

engine = On
; 是否启用PHP解析引擎。
; 可以在httpd.conf中基于目录或者虚拟主机来打开或者关闭PHP解析引擎。

last_modified = Off
; 是否在Last-Modified应答头中放置该PHP脚本的最后修改时间。

xbithack = Off
; 是否不管文件结尾是什么，都作为PHP可执行位组来解析。

child_terminate = Off
; PHP脚本在请求结束后是否允许使用apache_child_terminate()函数终止子进程。
; 该指令仅在UNIX平台上将PHP安装为Apache1.3的模块时可用。其他情况下皆不存在。

;;;;;;;;;;;;;;;
;; PHP核心 ;;
;;;;;;;;;;;;;;;

[PHP-Core-DateTime]
; 前四个配置选项目前仅用于date_sunrise()和date_sunset()函数。

date.default_latitude = 31.7667
; 默认纬度

date.default_longitude = 35.2333
; 默认经度

date.sunrise_zenith = 90.583333
; 默认日出天顶

date.sunset_zenith = 90.583333
; 默认日落天顶

date.timezone =
; 未设定TZ环境变量时用于所有日期和时间函数的默认时区。
; 中国大陆应当使用"PRC"
; 应用时区的优先顺序为：
; 1. 用date_default_timezone_set()函数设定的时区(如果设定了的话)
; 2. TZ 环境变量(如果非空的话)
; 3. 该指令的值(如果设定了的话)
; 4. PHP自己推测(如果操作系统支持)
; 5. 如果以上都不成功，则使用 UTC

[PHP-Core-Assert]

assert.active = On
; 是否启用assert()断言评估

assert.l = Off
; 是否在发生失败断言时中止脚本的执行

assert.callback =
; 发生失败断言时执行的回调函数

assert.quiet_eval = Off
; 是否使用安静评估(不显示任何错误信息，相当于error_reporting=0)。
; 若关闭则在评估断言表达式的时候使用当前的error_reporting指令值。

assert.warning = On
; 是否对每个失败断言都发出警告

[PHP-Core-SafeMode]
; 安全模式是为了解决共享服务器的安全问题而设立的。
; 但试图在PHP层解决这个问题在结构上是不合理的，
; 正确的做法应当是修改web服务器层和操作系统层。
; 因此在PHP6中废除了安全模式，并打算使用open_basedir指令取代之。

safe_mode = Off
;SYS
; 是否启用安全模式。
; 打开时，PHP将检查当前脚本的拥有者是否和被操作的文件的拥有者相同，
; 相同则允许操作，不同则拒绝操作。

safe_mode_gid = Off
;SYS
; 在安全模式下，默认在访问文件时会做UID比较检查。
; 但有些情况下严格的UID检查反而是不适合的，宽松的GID检查已经足够。
; 如果你想将其放宽到仅做GID比较，可以打开这个参数。

safe_mode_allowed_env_vars = "PHP_"
;SYS
; 在安全模式下，用户仅可以更改的环境变量的前缀列表(逗号分隔)。
; 允许用户设置某些环境变量，可能会导致潜在的安全漏洞。
; 注意: 如果这一参数值为空，PHP将允许用户更改任意环境变量！

safe_mode_protected_env_vars = "LD_LIBRARY_PATH"
;SYS
; 在安全模式下，用户不能更改的环境变量列表(逗号分隔)。
; 这些变量即使在safe_mode_allowed_env_vars指令设置为允许的情况下也会得到保护。

safe_mode_exec_dir = "/usr/local/php/bin"
;SYS
; 在安全模式下，只有该目录下的可执行程序才允许被执行系统程序的函数执行。
; 这些函数是：system, escapeshellarg, escapeshellcmd, exec, passthru,
; proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec

safe_mode_include_dir =
;SYS
; 在安全模式下，该组目录和其子目录下的文件被包含时，将跳过UID/GID检查。
; 换句话说，如果此处的值为空，任何UID/GID不符合的文件都不允许被包含。
; 这里设置的目录必须已经存在于include_path指令中或者用完整路径来包含。
; 多个目录之间用冒号(Win下为分号)隔开。
; 指定的限制实际上是一个前缀，而非一个目录名，
; 也就是说"/dir/incl"将允许访问"/dir/include"和"/dir/incls"
; 如果您希望将访问控制在一个指定的目录，那么请在结尾加上斜线。

sql.safe_mode = Off
;SYS
; 是否使用SQL安全模式。
; 如果打开，指定默认值的数据库连接函数将会使用这些默认值代替支持的参数。
; 对于每个不同数据库的连接函数，其默认值请参考相应的手册页面。

[PHP-Core-Safe]

allow_url_fopen = On
;ini
; 是否允许打开远程文件

allow_url_include = Off
;SYS
; 是否允许include/require远程文件。

disable_classes =
;ini
; 该指令接受一个用逗号分隔的类名列表，以禁用特定的类。

disable_functions =
;ini
; 该指令接受一个用逗号分隔的函数名列表，以禁用特定的函数。

enable_dl = On
;SYS
; 是否允许使用dl()函数。dl()函数仅在将PHP作为apache模块安装时才有效。
; 禁用dl()函数主要是出于安全考虑，因为它可以绕过open_basedir指令的限制。
; 在安全模式下始终禁用dl()函数，而不管此处如何设置。

expose_php = On
;ini
; 是否暴露PHP被安装在服务器上的事实(在http头中加上其签名)。
; 它不会有安全上的直接威胁，但它使得客户端知道服务器上安装了PHP。

open_basedir =
;SYS
; 将PHP允许操作的所有文件(包括文件自身)都限制在此组目录列表下。
; 当一个脚本试图打开一个指定目录树之外的文件时，将遭到拒绝。
; 所有的符号连接都会被解析，所以不可能通过符号连接来避开此限制。
; 特殊值'.'指定了存放该脚本的目录将被当做基准目录。
; 但这有些危险，因为脚本的工作目录可以轻易被chdir()改变。
; 对于共享服务器，在httpd.conf中灵活设置该指令将变得非常有用。
; 在Windows中用分号分隔目录，UNIX系统中用冒号分隔目录。
; 作为Apache模块时，父目录中的open_basedir路径将自动被继承。
; 指定的限制实际上是一个前缀，而非一个目录名，
; 也就是说"/dir/incl"将允许访问"/dir/include"和"/dir/incls"，
; 如果您希望将访问控制在一个指定的目录，那么请在结尾加上一个斜线。
; 默认是允许打开所有文件。

[PHP-Core-Error]

error_reporting = E_ALL & ~E_NOTICE
; 错误报告级别是位字段的叠加，推荐使用 E_ALL | E_STRICT
; 1 E_ERROR 致命的运行时错误
; 2 E_WARNING 运行时警告(非致命性错误)
; 4 E_PARSE 编译时解析错误
; 8 E_NOTICE 运行时提醒(经常是bug，也可能是有意的)
; 16 E_CORE_ERROR PHP启动时初始化过程中的致命错误
; 32 E_CORE_WARNING PHP启动时初始化过程中的警告(非致命性错)
; 64 E_COMPILE_ERROR 编译时致命性错
; 128 E_COMPILE_WARNING 编译时警告(非致命性错)
; 256 E_USER_ERROR 用户自定义的致命错误
; 512 E_USER_WARNING 用户自定义的警告(非致命性错误)
; 1024 E_USER_NOTICE 用户自定义的提醒(经常是bug，也可能是有意的)
; 2048 E_STRICT 编码标准化警告(建议如何修改以向前兼容)
; 4096 E_RECOVERABLE_ERROR 接近致命的运行时错误，若未被捕获则视同E_ERROR
; 6143 E_ALL 除E_STRICT外的所有错误(PHP6中为8191,即包含所有)

track_errors = Off
; 是否在变量$php_errormsg中保存最近一个错误或警告消息。

display_errors = On
; 是否将错误信息作为输出的一部分显示。
; 在最终发布的web站点上，强烈建议你关掉这个特性，并使用错误日志代替(参看下面)。
; 在最终发布的web站点打开这个特性可能暴露一些安全信息，
; 例如你的web服务上的文件路径、数据库规划或别的信息。

display_startup_errors = Off
; 是否显示PHP启动时的错误。
; 即使display_errors指令被打开，关闭此参数也将不显示PHP启动时的错误。
; 建议你关掉这个特性，除非你必须要用于调试中。

report_memleaks = On
; 是否报告内存泄漏。这个参数只在以调试方式编译的PHP中起作用，
; 并且必须在error_reporting指令中包含 E_WARNING

report_zend_debug = On
; 尚无说明文档

html_errors = On
; 是否在出错信息中使用HTML标记。
; 注意: 不要在发布的站点上使用这个特性！

docref_root = ;"http://localhost/phpmanual/"
docref_ext = ;".html"
; 如果打开了html_errors指令，PHP将会在出错信息上显示超连接，
; 直接链接到一个说明这个错误或者导致这个错误的函数的页面。
; 你可以从http://www.php.net/docs.php下载php手册，
; 并将docref_root指令指向你本地的手册所在的URL目录。
; 你还必须设置docref_ext指令来指定文件的扩展名(必须含有'.')。
; 注意: 不要在发布的站点上使用这个特性。

error_prepend_string = ;"<font color=#f00>"
; 用于错误信息前输出的字符串
error_append_string = ;"</font>"
; 用于错误信息后输出的字符串

xmlrpc_errors = Off
xmlrpc_error_number = 0
; 尚无文档

[PHP-Core-Logging]

define_syslog_variables = Off
; 是否定义各种系统日志变量，如：$LOG_PID, $LOG_CRON 等等。
; 关掉它以提高效率的好主意。
; 你可以在运行时调用define_syslog_variables()函数来定义这些变量。

error_log =
; 将错误日志记录到哪个文件中。该文件必须对Web服务器用户可写。
; syslog 表示记录到系统日志中(NT下的事件日志, Unix下的syslog(3))
; 如果此处未设置任何值，则错误将被记录到Web服务器的错误日志中。

log_errors = Off
; 是否在日志文件里记录错误，具体在哪里记录取决于error_log指令。
; 强烈建议你在最终发布的web站点时使用日志记录错误而不是直接输出，
; 这样可以让你既知道那里出了问题，又不会暴露敏感信息。

log_errors_max_len = 1024
; 设置错误日志中附加的与错误信息相关联的错误源的最大长度。
; 这里设置的值对显示的和记录的错误以及$php_errormsg都有效。
; 设为 0 可以允许无限长度。

ignore_repeated_errors = Off
; 记录错误日志时是否忽略重复的错误信息。
; 错误信息必须出现在同一文件的同一行才被被视为重复。

ignore_repeated_source = Off
; 是否在忽略重复的错误信息时忽略重复的错误源。

[PHP-Core-Mail]
; 要使邮件函数可用，PHP必须在编译时能够访问sendmail程序。
; 如果使用其它的邮件程序，如qmail或postfix，确保使用了相应的sendmail包装。
; PHP首先会在系统的PATH环境变量中搜索sendmail，接着按以下顺序搜索：
; /usr/bin:/usr/sbin:/usr/etc:/etc:/usr/ucblib:/usr/lib
; 强烈建议在PATH中能够找到sendmail。
; 另外，编译PHP的用户必须能够访问sendmail程序。

SMTP = "localhost"
; mail()函数中用来发送邮件的SMTP服务器的主机名称或者IP地址。仅用于win32。

smtp_port = 25
; SMTP服务器的端口号。仅用于win32。

sendmail_from =
; 发送邮件时使用的"From:"头中的邮件地址。仅用于win32
; 该选项还同时设置了"Return-Path:"头。

sendmail_path = "-t -i"
;SYS
; 仅用于unix，也可支持参数(默认的是'sendmail -t -i')
; sendmail程序的路径，通常为"/usr/sbin/sendmail或/usr/lib/sendmail"。
; configure脚本会尝试找到该程序并设定为默认值，但是如果失败的话，可以在这里设定。
; 不使用sendmail的系统应将此指令设定为sendmail替代程序(如果有的话)。
; 例如，Qmail用户通常可以设为"/var/qmail/bin/sendmail"或"/var/qmail/bin/qmail-inject"。
; qmail-inject 不需要任何选项就能正确处理邮件。

mail.force_extra_parameters =
; 作为额外的参数传递给sendmail库的强制指定的参数附加值。
; 这些参数总是会替换掉mail()的第5个参数，即使在安全模式下也是如此。

[PHP-Core-ResourceLimit]

default_socket_timeout = 60
; 默认socket超时(秒)

max_execution_time = 30
; 每个脚本最大允许执行时间(秒)，0 表示没有限制。
; 这个参数有助于阻止劣质脚本无休止的占用服务器资源。
; 该指令仅影响脚本本身的运行时间，任何其它花费在脚本运行之外的时间，
; 如用system()/sleep()函数的使用、数据库查询、文件上传等，都不包括在内。
; 在安全模式下，你不能用ini_set()在运行时改变这个设置。

memory_limit = 16M
; 一个脚本所能够申请到的最大内存字节数(可以使用K和M作为单位)。
; 这有助于防止劣质脚本消耗完服务器上的所有内存。
; 要能够使用该指令必须在编译时使用"--enable-memory-limit"配置选项。
; 如果要取消内存限制，则必须将其设为 -1 。
; 设置了该指令后，memory_get_usage()函数将变为可用。

max_input_time = -1
; 每个脚本解析输入数据(POST, GET, upload)的最大允许时间(秒)。
; -1 表示不限制。

post_max_size = 8M
; 允许的POST数据最大字节长度。此设定也影响到文件上传。
; 如果POST数据超出限制，那么___FCKpd___0

POST和
___FCKpd___0

FILES将会为空。
; 要上传大文件，该值必须大于upload_max_filesize指令的值。
; 如果启用了内存限制，那么该值应当小于memory_limit指令的值。

realpath_cache_size = 16K
;SYS
; 指定PHP使用的realpath(规范化的绝对路径名)缓冲区大小。
; 在PHP打开大量文件的系统上应当增大该值以提高性能。

realpath_cache_ttl = 120
;SYS
; realpath缓冲区中信息的有效期(秒)。
; 对文件很少变动的系统，可以增大该值以提高性能。

[PHP-Core-FileUpLoad]

file_uploads = On
;SYS
; 是否允许HTTP文件上传。
; 参见upload_max_filesize, upload_tmp_dir, post_max_size指令

upload_max_filesize = 2M
; 允许上传的文件的最大尺寸。

upload_tmp_dir =
;SYS
; 文件上传时存放文件的临时目录(必须是PHP进程用户可写的目录)。
; 如果未指定则PHP使用系统默认的临时目录。

[PHP-Core-MagicQuotes]
; PHP6将取消魔术引号，相当于下列指令全部为 Off

magic_quotes_gpc = On
; 是否对输入的GET/POST/Cookie数据使用自动字符串转义( ' " \ NULL )。
; 这里的设置将自动影响
___FCKpd___0

GEST
___FCKpd___0

POST
___FCKpd___0

COOKIE 数组的值。
; 若将本指令与magic_quotes_sybase指令同时打开，则仅将单引号(')转义为('')，
; 其它特殊字符将不被转义，即( " \ NULL )将保持原样！！
; 建议关闭此特性，并使用自定义的过滤函数。

magic_quotes_runtime = Off
; 是否对运行时从外部资源产生的数据使用自动字符串转义( ' " \ NULL )。
; 若打开本指令，则大多数函数从外部资源(数据库,文本文件等)返回数据都将被转义。
; 例如：用SQL查询得到的数据，用exec()函数得到的数据，等等
; 若将本指令与magic_quotes_sybase指令同时打开，则仅将单引号(')转义为('')，
; 其它特殊字符将不被转义，即( " \ NULL )将保持原样！！
; 建议关闭此特性，并视具体情况使用自定义的过滤函数。

magic_quotes_sybase = Off
; 是否采用Sybase形式的自动字符串转义(用 '' 表示 ')

[PHP-Core-HighLight]

highlight.bg = "#FFFFFF"
highlight.comment = "#FF8000"
highlight.default = "#0000BB"
highlight.html = "#000000"
highlight.keyword = "#007700"
highlight.string = "#DD0000"
; 语法高亮模式的色彩(通常用于显示 .phps 文件)。
; 只要能被<font color=xxx>接受的东西就能正常工作。

[PHP-Core-Langue]

short_open_tag = On
; 是否允许使用"<? ?>"短标识。否则必须使用"<?php ?>"长标识。
; 除非你的php程序仅在受控环境下运行，且只供自己使用，否则请不要使用短标记。
; 如果要和XML结合使用PHP，可以选择关闭此选项以方便直接嵌入"<?xml ... ?>"，
; 不然你必须用PHP来输出：<? echo '<?xml version="1.0"'; ?>
; 本指令也会影响到缩写形式"<?="，它和"<? echo"等价，要使用它也必须打开短标记。

asp_tags = Off
; 是否允许ASP风格的标记"<% %>"，这也会影响到缩写形式"<%="。
; PHP6中将删除此指令

arg_separator.output = "&"
; PHP所产生的URL中用来分隔参数的分隔符。
; 另外还可以用"&"或","等等。

arg_separator.input = "&"
; PHP解析URL中的变量时使用的分隔符列表。
; 字符串中的每一个字符都会被当作分割符。
; 另外还可以用",&"等等。

allow_call_time_pass_reference = On
; 是否强迫在函数调用时按引用传递参数(每次使用此特性都会收到一条警告)。
; php反对这种做法，并在将来的版本里不再支持，因为它影响到了代码的整洁。
; 鼓励的方法是在函数声明里明确指定哪些参数按引用传递。
; 我们鼓励你关闭这一选项，以保证你的脚本在将来版本的语言里仍能正常工作。

auto_globals_jit = On
; 是否仅在使用到
___FCKpd___0

SERVER和
___FCKpd___0

ENV变量时才创建(而不是在脚本一启动时就自动创建)。
; 如果并未在脚本中使用这两个数组，打开该指令将会获得性能上的提升。
; 要想该指令生效，必须关闭register_globals和register_long_arrays指令。

auto_prepend_file =
auto_append_file =
; 指定在主文件之前/后自动解析的文件名。为空表示禁用该特性。
; 该文件就像调用了include()函数被包含进来一样，因此会使用include_path指令的值。
; 注意：如果脚本通过exit()终止，那么自动后缀将不会发生。

variables_order = "EGPCS"
; PHP注册 Environment, GET, POST, Cookie, Server 变量的顺序。
; 分别用 E, G, P, C, S 表示，按从左到右注册，新值覆盖旧值。
; 举例说，设为"GP"将会导致用POST变量覆盖同名的GET变量，
; 并完全忽略 Environment, Cookie, Server 变量。
; 推荐使用"GPC"或"GPCS"，并使用getenv()函数访问环境变量。

register_globals = Off
; 是否将 E, G, P, C, S 变量注册为全局变量。
; 打开该指令可能会导致严重的安全问题，除非你的脚本经过非常仔细的检查。
; 推荐使用预定义的超全局变量：
___FCKpd___0

ENV,
___FCKpd___0

GET,
___FCKpd___0

POST,
___FCKpd___0

COOKIE,
___FCKpd___0

SERVER
; 该指令受variables_order指令的影响。
; PHP6中已经删除此指令。

register_argc_argv = On
; 是否声明$argv和$argc全局变量(包含用GET方法的信息)。
; 建议不要使用这两个变量，并关掉该指令以提高性能。

register_long_arrays = On
; 是否启用旧式的长式数组(HTTP_*_VARS)。
; 鼓励使用短式的预定义超全局数组，并关闭该特性以获得更好的性能。
; PHP6中已经删除此指令。

always_populate_raw_post_data = Off
; 是否总是生成$HTTP_RAW_POST_DATA变量(原始POST数据)。
; 否则，此变量仅在遇到不能识别的MIME类型的数据时才产生。
; 不过，访问原始POST数据的更好方法是 php://input 。
; $HTTP_RAW_POST_DATA对于enctype="multipart/form-data"的表单数据不可用。

unserialize_callback_func =
; 如果解序列化处理器需要实例化一个未定义的类，
; 这里指定的回调函数将以该未定义类的名字作为参数被unserialize()调用，
; 以免得到不完整的"__PHP_Incomplete_Class"对象。
; 如果这里没有指定函数，或指定的函数不包含(或实现)那个未定义的类，将会显示警告信息。
; 所以仅在确实需要实现这样的回调函数时才设置该指令。
; 若要禁止这个特性，只需置空即可。

y2k_compliance = On
; 是否强制打开2000年适应(可能在非Y2K适应的浏览器中导致问题)。

zend.ze1_compatibility_mode = Off
; 是否使用兼容Zend引擎I(PHP 4.x)的模式。
; 这将影响对象的复制、构造(无属性的对象会产生FALSE或0)、比较。
; 兼容模式下，对象将按值传递，而不是默认的按引用传递。

precision = 14
; 浮点型数据显示的有效位数。

serialize_precision = 100
; 将浮点型和双精度型数据序列化存储时的精度(有效位数)。
; 默认值能够确保浮点型数据被解序列化程序解码时不会丢失数据。

[PHP-Core-OutputControl]
; 输出控制函数很有用，特别是在已经输出了信息之后再发送HTTP头的情况下。
; 输出控制函数不会作用于header()或setcookie()等函数发送的HTTP头，
; 而只会影响类似于echo()函数输出的信息和嵌入在PHP代码之间的信息。

implicit_flush = Off
; 是否要求PHP输出层在每个输出块之后自动刷新数据。
; 这等效于在每个 print()、echo()、HTML块 之后自动调用flush()函数。
; 打开这个选项对程序执行的性能有严重的影响，通常只推荐在调试时使用。
; 在CLI SAPI的执行模式下，该指令默认为 On 。

output_buffering = 0
; 输出缓冲区大小(字节)。建议值为4096~8192。
; 输出缓冲允许你甚至在输出正文内容之后再发送HTTP头(包括cookies)。
; 其代价是输出层减慢一点点速度。
; 设置输出缓冲可以减少写入，有时还能减少网络数据包的发送。
; 这个参数的实际收益很大程度上取决于你使用的是什么Web服务器以及什么样的脚本。

output_handler =
; 将所有脚本的输出重定向到一个输出处理函数。
; 比如，重定向到mb_output_handler()函数时，字符编码将被透明地转换为指定的编码。
; 一旦你在这里指定了输出处理程序，输出缓冲将被自动打开(output_buffering=4096)。
; 注意0: 此处仅能使用PHP内置的函数，自定义函数应在脚本中使用ob_start()指定。
; 注意1: 可移植脚本不能依赖该指令，而应使用ob_start()函数明确指定输出处理函数。
; 使用这个指令可能会导致某些你不熟悉的脚本出错。
; 注意2: 你不能同时使用"mb_output_handler"和"ob_iconv_handler"两个输出处理函数。
; 你也不能同时使用"ob_gzhandler"输出处理函数和zlib.output_compression指令。
; 注意3: 如果使用zlib.output_handler指令开启zlib输出压缩，该指令必须为空。

Ⅶ 我想学编程，应该学哪一类，求助

先学c和c++

Ⅷ Web应用安全威胁与防治——基于OWASP Top 10与ESAPI的目录

第1篇 引子
故事一：家有一IT，如有一宝 2
故事二：微博上的蠕虫 3
故事三：明文密码 5
故事四：IT青年VS禅师 5
第2篇 基础篇
第1章 Web应用技术 8
1.1 HTTP简介 8
1.2 HTTPS简介 10
1.3 URI 11
1.3.1 URL 11
1.3.2 URI/URL/URN 12
1.3.3 URI比较 13
1.4 HTTP消息 13
1.4.1 HTTP方法14
1.4.2 HTTP状态码 19
1.5 HTTP Cookie20
1.5.1 HTTP Cookie的作用22
1.5.2 HTTP Cookie的缺点23
1.6 HTTP session23
1.7 HTTP的安全 24
第2章 OWASP 27
2.1 OWASP简介27
2.2 OWASP风险评估方法28
2.3 OWASP Top 10 34
2.4 ESAPI（Enterprise Security API） 35
第3篇 工具篇
第3章 Web服务器工具简介 38
3.1 Apache 38
3.2 其他Web服务器 39
第4章 Web浏览器以及调试工具 42
4.1 浏览器简介 42
4.1.1 基本功能 42
4.1.2 主流浏览器 43
4.1.3 浏览器内核 44
4.2 开发调试工具 45
第5章 渗透测试工具 47
5.1 Fiddler 47
5.1.1 工作原理 47
5.1.2 如何捕捉HTTPS会话 48
5.1.3 Fiddler功能介绍 49
5.1.4 Fiddler扩展功能 56
5.1.5 Fiddler第三方扩展功能 56
5.2 ZAP 58
5.2.1 断点调试 60
5.2.2 编码/解码 61
5.2.3 主动扫描 62
5.2.4 Spider63
5.2.5 暴力破解 64
5.2.6 端口扫描 65
5.2.7 Fuzzer66
5.2.8 API 66
5.3 WebScrab 67
5.3.1 HTTP代理67
5.3.2 Manual Request 69
5.3.3 Spider70
5.3.4 Session ID分析71
5.3.5 Bean Shell的支持 71
5.3.6 Web编码和解码 73
第6章 扫描工具简介 74
6.1 万能的扫描工具——WebInspect 74
6.1.1 引言 74
6.1.2 WebInspect特性 74
6.1.3 环境准备 74
6.1.4 HP WebInspect总览 76
6.1.5 Web网站测试 79
6.1.6 企业测试 86
6.1.7 生成报告 88
6.2 开源扫描工具——w3af 91
6.2.1 w3af概述 91
6.2.2 w3af环境配置 92
6.2.3 w3af使用示例 93
6.3 被动扫描的利器——Ratproxy 94
6.3.1 Ratproxy概述 94
6.3.2 Ratproxy环境配置 95
6.3.3 Ratproxy运行 96
第7章 漏洞学习网站 98
7.1 WebGoat 98
7.2 DVWA 99
7.3 其他的漏洞学习网站 99
第4篇 攻防篇
第8章 代码注入 102
8.1 注入的分类 104
8.1.1 OS命令注入 104
8.1.2 XPath注入109
8.1.3 LDAP注入114
8.1.4 SQL注入 118
8.1.5 JSON注入131
8.1.6 URL参数注入 133
8.2 OWASP ESAPI与注入问题的预防 135
8.2.1 命令注入的ESAPI预防 135
8.2.2 XPath注入的ESAPI预防 138
8.2.3 LDAP注入的ESAPI预防 138
8.2.4 SQL注入的ESAPI预防 141
8.2.5 其他注入的ESAPI预防 143
8.3 注入预防检查列表 143
8.4 小结 144
第9章 跨站脚本（XSS）146
9.1 XSS简介 146
9.2 XSS分类 146
9.2.1 反射式XSS 146
9.2.2 存储式XSS 148
9.2.3 基于DOM的XSS 149
9.2.4 XSS另一种分类法 151
9.3 XSS危害 154
9.4 XSS检测 156
9.4.1 手动检测 156
9.4.2 半自动检测 158
9.4.3 全自动检测 158
9.5 XSS的预防 159
9.5.1 一刀切 159
9.5.2 在服务器端预防 160
9.5.3 在客户端预防 168
9.5.4 富文本框的XSS预防措施 170
9.5.5 CSS 172
9.5.6 FreeMarker174
9.5.7 OWASP ESAPI与XSS的预防 177
9.6 XSS检查列表 183
9.7 小结 184
第10章 失效的身份认证和会话管理 185
10.1 身份认证和会话管理简介185
10.2 谁动了我的琴弦——会话劫持186
10.3 请君入瓮——会话固定 188
10.4 我很含蓄——非直接会话攻击191
10.5 如何测试 199
10.5.1 会话固定测试 199
10.5.2 用Web Scrab分析会话ID 200
10.6 如何预防会话攻击 202
10.6.1 如何防治固定会话 202
10.6.2 保护你的会话令牌 204
10.7 身份验证 208
10.7.1 双因子认证流程图 209
10.7.2 双因子认证原理说明 210
10.7.3 隐藏在QR Code里的秘密 211
10.7.4 如何在服务器端实现双因子认证 212
10.7.5 我没有智能手机怎么办 216
10.8 身份认证设计的基本准则216
10.8.1 密码长度和复杂性策略 216
10.8.2 实现一个安全的密码恢复策略 217
10.8.3 重要的操作应通过HTTPS传输 217
10.8.4 认证错误信息以及账户锁定 219
10.9 检查列表 219
10.9.1 身份验证和密码管理检查列表 219
10.9.2 会话管理检查列表 220
10.10 小结 221
第11章 不安全的直接对象引用 222
11.1 坐一望二——直接对象引用 222
11.2 不安全直接对象引用的危害 224
11.3 其他可能的不安全直接对象引用 224
11.4 不安全直接对象引用的预防 225
11.5 如何使用OWASP ESAPI预防 227
11.6 直接对象引用检查列表 230
11.7 小结 230
第12章 跨站请求伪造（CSRF） 232
12.1 CSRF简介 232
12.2 谁动了我的奶酪232
12.3 跨站请求伪造的攻击原理233
12.4 剥茧抽丝见真相235
12.5 其他可能的攻击场景236
12.5.1 家用路由器被CSRF攻击 236
12.5.2 别以为用POST你就躲过了CSRF 238
12.5.3 写一个自己的CSRF Redirector 241
12.5.4 利用重定向欺骗老实人 243
12.6 跨站请求伪造的检测245
12.6.1 手工检测 245
12.6.2 半自动CSRFTester 246
12.7 跨站请求伪造的预防250
12.7.1 用户需要知道的一些小技巧 250
12.7.2 增加一些确认操作 250
12.7.3 重新认证 250
12.7.4 加入验证码（CAPTCHA） 250
12.7.5 ESAPI解决CSRF 250
12.7.6 CSRFGuard 256
12.8 CSRF检查列表 260
12.9 小结 261
第13章 安全配置错误 262
13.1 不能说的秘密——Google hacking 262
13.2 Tomcat那些事 264
13.3 安全配置错误的检测与预防 264
13.3.1 系统配置 264
13.3.2 Web应用服务器的配置 268
13.3.3 数据库 282
13.3.4 日志配置 284
13.3.5 协议 285
13.3.6 开发相关的安全配置 291
13.3.7 编译器的安全配置 302
13.4 安全配置检查列表 305
13.5 小结 307
第14章 不安全的加密存储 308
14.1 关于加密 310
14.1.1 加密算法简介 310
14.1.2 加密算法作用 312
14.1.3 加密分类 313
14.2 加密数据分类 314
14.3 加密数据保护 315
14.3.1 密码的存储与保护 315
14.3.2 重要信息的保护 323
14.3.3 密钥的管理 336
14.3.4 数据的完整性 339
14.3.5 云系统存储安全 342
14.3.6 数据保护的常犯错误 343
14.4 如何检测加密存储数据的安全性 344
14.4.1 审查加密内容 344
14.4.2 已知答案测试（Known Answer Test）344
14.4.3 自发明加密算法的检测 345
14.4.4 AES加密算法的测试 345
14.4.5 代码审查 346
14.5 如何预防不安全的加密存储的数据347
14.6 OWASP ESAPI与加密存储 348
14.6.1 OWASP ESAPI与随机数 353
14.6.2 OWASP ESAPI 与FIPS 140-2 354
14.7 加密存储检查列表 355
14.8 小结 355
第15章 没有限制的URL访问357
15.1 掩耳盗铃——隐藏（Disable）页面按钮357
15.2 权限认证模型 358
15.2.1 自主型访问控制 360
15.2.2 强制型访问控制 360
15.2.3 基于角色的访问控制 361
15.3 绕过认证 363
15.3.1 网络嗅探 364
15.3.2 默认或者可猜测用户账号 364
15.3.3 直接访问内部URL364
15.3.4 修改参数绕过认证 365
15.3.5 可预测的SessionID365
15.3.6 注入问题 365
15.3.7 CSRF 365
15.3.8 绕过认证小结 366
15.4 绕过授权验证 367
15.4.1 水平越权 368
15.4.2 垂直越权 369
15.5 文件上传与下载373
15.5.1 文件上传 373
15.5.2 文件下载和路径遍历 377
15.6 静态资源 382
15.7 后台组件之间的认证383
15.8 SSO 385
15.9 OWASP ESAPI与授权 386
15.9.1 AccessController的实现387
15.9.2 一个AccessController的代码示例390
15.9.3 我们还需要做些什么 391
15.10 访问控制检查列表 393
15.11 小结 393
第16章 传输层保护不足 395
16.1 卧底的故事——对称加密和非对称加密395
16.2 明文传输问题 396
16.3 有什么危害398
16.3.1 会话劫持 398
16.3.2 中间人攻击 399
16.4 预防措施 399
16.4.1 密钥交换算法 400
16.4.2 对称加密和非对称加密结合 401
16.4.3 SSL/TLS 406
16.5 检查列表 423
16.6 小结 423
第17章 未验证的重定向和转发 425
17.1 三角借贷的故事——转发和重定向425
17.1.1 URL转发425
17.1.2 URL重定向 426
17.1.3 转发与重定向的区别 429
17.1.4 URL 重定向的实现方式 430
17.2 危害 438
17.3 如何检测 439
17.4 如何预防 440
17.4.1 OWASP ESAPI与预防 441
17.5 重定向和转发检查列表 443
17.6 小结 443
第5篇 安全设计、编码十大原则
第18章 安全设计十大原则 448
设计原则1——简单易懂 448
设计原则2——最小特权 448
设计原则3——故障安全化450
设计原则4——保护最薄弱环节451
设计原则5——提供深度防御 452
设计原则6——分隔 453
设计原则7——总体调节 454
设计原则8——默认不信任454
设计原则9——保护隐私 455
设计原则10——公开设计，不要假设隐藏秘密就是安全 455
第19章 安全编码十大原则 457
编码原则1——保持简单 457
编码原则2——验证输入 458
编码原则3——注意编译器告警459
编码原则4——框架和设计要符合安全策略 459
编码原则5——默认拒绝 460
编码原则6——坚持最小权限原则 462
编码原则7——净化发送到其他系统的数据 463
编码原则8——深度预防 464
编码原则9——使用有效的质量保证技术464
编码原则10——采用一个安全编码规范 465
媒体评论
这是一本带点酷酷的工程师范儿和人文气质的“硬货”。作为一名资深IT文艺老人，特别喜欢这种带着思想气息却又有着丰富案例娓娓道来的实用信息安全书，过去却往往只在国外作者中读到。正如书中开头的引子说的那样：“家有IT，如有一宝。”那么在Web安全日益火爆的今天，你会不会在读完这本书后的未来也成为传说中让我们顶礼膜拜的大牛呢^-^
——IDF威慑防御实验室益云（公益互联网）社会创新中心联合创始人万涛@黑客老鹰
伴随互联网的高速发展，基于B/S架构的业务系统对安全要求越来越高，安全从业人员面临空前的压力。如何让安全从业人员快速掌握Web应用安全？本书以诙谐、幽默的语言，精彩、丰富的实例，帮助安全从业人员从端到端理解Web应用安全。不失为近几年Web应用安全书籍的上佳之作。
——OWASP中国区主席SecZone高级安全顾问 RIP
很乐意看到有人将自身的资深安全积累和OWASP的最佳实践出版成书，内容严谨细致却不乏生动。这本信息安全领域的实用手册将成为银基安全致力于互联网安全的参考指导书目之一，我们广泛的电信、银行、保险、证券和政府部门等客户都会从中受益。
——上海银基信息安全技术有限公司首席技术官胡绍勇（Kurau）
随着安全访问控制策略ACL的普及应用，互联网企业目前面临的安全风险面主要集中在Web服务层。其中Web应用系统在架构设计、开发编码过程中是安全漏洞和风险引入的主要阶段，而普遍地我们的架构、开发、测试岗位在安全技能与意识上恰恰是相对比较欠缺的。本书详细介绍了Web安全基础知识、测试平台与方法，常见漏洞形式与原理，并结合OWASP最佳实践经验给出预防建议、设计和编码原则等。书中举例生动形象，图文代码并茂，步骤归纳清晰。特别推荐给广大Web开发、测试、安全岗位的朋友们。
—— 中国金山软件集团信息安全负责人程冲
在网络攻击愈加复杂，手段日益翻新的今天，Web攻击依然是大多数攻击者首选的入侵手段。反思CSDN泄密及新浪微博蠕虫事件，Web应用的安全突显其重要性。OWASP作为全球领先的Web应用安全研究团队，透过本书将Web应用安全的威胁、防御以及相关的工具进行了详细的探讨和研究。详尽的操作步骤说明是本书的亮点之一，这些详实且图文并茂的内容为逐步深入学习Web应用安全提供了很好的帮助。我衷心希望这本书能够成为信息安全专业的在校生以及应用安全相关从业人员的学习指导书。
-- 上海交通大学信息安全工程学院施勇(CISSP CISA)

Ⅸ web漏洞攻击有哪些

一、SQL注入漏洞
SQL注入攻击（SQL Injection），简称注入攻击、SQL注入，被广泛用于非法获取网站控制权，是发生在应用程序的数据库层上的安全漏洞。在设计程序，忽略了对输入字符串中夹带的SQL指令的检查，被数据库误认为是正常的SQL指令而运行，从而使数据库受到攻击，可能导致数据被窃取、更改、删除，以及进一步导致网站被嵌入恶意代码、被植入后门程序等危害。
通常情况下，SQL注入的位置包括：
（1）表单提交，主要是POST请求，也包括GET请求；
（2）URL参数提交，主要为GET请求参数；
（3）Cookie参数提交；
（4）HTTP请求头部的一些可修改的值，比如Referer、User_Agent等；
（5）一些边缘的输入点，比如.mp3文件的一些文件信息等。
常见的防范方法
（1）所有的查询语句都使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。当前几乎所有的数据库系统都提供了参数化SQL语句执行接口，使用此接口可以非常有效的防止SQL注入攻击。
（2）对进入数据库的特殊字符（’”<>&*;等）进行转义处理，或编码转换。
（3）确认每种数据的类型，比如数字型的数据就必须是数字，数据库中的存储字段必须对应为int型。
（4）数据长度应该严格规定，能在一定程度上防止比较长的SQL注入语句无法正确执行。
（5）网站每个数据层的编码统一，建议全部使用UTF-8编码，上下层编码不一致有可能导致一些过滤模型被绕过。
（6）严格限制网站用户的数据库的操作权限，给此用户提供仅仅能够满足其工作的权限，从而最大限度的减少注入攻击对数据库的危害。
（7）避免网站显示SQL错误信息，比如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断。
（8）在网站发布之前建议使用一些专业的SQL注入检测工具进行检测，及时修补这些SQL注入漏洞。

二、跨站脚本漏洞
跨站脚本攻击（Cross-site scripting，通常简称为XSS）发生在客户端，可被用于进行窃取隐私、钓鱼欺骗、窃取密码、传播恶意代码等攻击。
XSS攻击使用到的技术主要为HTML和Javascript，也包括VBScript和ActionScript等。XSS攻击对WEB服务器虽无直接危害，但是它借助网站进行传播，使网站的使用用户受到攻击，导致网站用户帐号被窃取，从而对网站也产生了较严重的危害。
XSS类型包括：
（1）非持久型跨站：即反射型跨站脚本漏洞，是目前最普遍的跨站类型。跨站代码一般存在于链接中，请求这样的链接时，跨站代码经过服务端反射回来，这类跨站的代码不存储到服务端（比如数据库中）。上面章节所举的例子就是这类情况。
（2）持久型跨站：这是危害最直接的跨站类型，跨站代码存储于服务端（比如数据库中）。常见情况是某用户在论坛发贴，如果论坛没有过滤用户输入的Javascript代码数据，就会导致其他浏览此贴的用户的浏览器会执行发贴人所嵌入的Javascript代码。
（3）DOM跨站（DOM XSS）：是一种发生在客户端DOM（Document Object Model文档对象模型）中的跨站漏洞，很大原因是因为客户端脚本处理逻辑导致的安全问题。
常用的防止XSS技术包括：
（1）与SQL注入防护的建议一样，假定所有输入都是可疑的，必须对所有输入中的script、iframe等字样进行严格的检查。这里的输入不仅仅是用户可以直接交互的输入接口，也包括HTTP请求中的Cookie中的变量，HTTP请求头部中的变量等。
（2）不仅要验证数据的类型，还要验证其格式、长度、范围和内容。
（3）不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。
（4）对输出的数据也要检查，数据库里的值有可能会在一个大网站的多处都有输出，即使在输入做了编码等操作，在各处的输出点时也要进行安全检查。
（5）在发布应用程序之前测试所有已知的威胁。

三、弱口令漏洞
弱口令(weak password) 没有严格和准确的定义，通常认为容易被别人（他们有可能对你很了解）猜测到或被破解工具破解的口令均为弱口令。设置密码通常遵循以下原则：
（1）不使用空口令或系统缺省的口令，这些口令众所周之，为典型的弱口令。
（2）口令长度不小于8个字符。
（3）口令不应该为连续的某个字符（例如：AAAAAAAA）或重复某些字符的组合（例如：tzf.tzf.）。
（4）口令应该为以下四类字符的组合，大写字母(A-Z)、小写字母(a-z)、数字(0-9)和特殊字符。每类字符至少包含一个。如果某类字符只包含一个，那么该字符不应为首字符或尾字符。
（5）口令中不应包含本人、父母、子女和配偶的姓名和出生日期、纪念日期、登录名、E-mail地址等等与本人有关的信息，以及字典中的单词。
（6）口令不应该为用数字或符号代替某些字母的单词。
（7）口令应该易记且可以快速输入，防止他人从你身后很容易看到你的输入。
（8）至少90天内更换一次口令，防止未被发现的入侵者继续使用该口令。

四、HTTP报头追踪漏洞
HTTP/1.1（RFC2616）规范定义了HTTP TRACE方法，主要是用于客户端通过向Web服务器提交TRACE请求来进行测试或获得诊断信息。当Web服务器启用TRACE时，提交的请求头会在服务器响应的内容（Body）中完整的返回，其中HTTP头很可能包括Session Token、Cookies或其它认证信息。攻击者可以利用此漏洞来欺骗合法用户并得到他们的私人信息。该漏洞往往与其它方式配合来进行有效攻击，由于HTTP TRACE请求可以通过客户浏览器脚本发起（如XMLHttpRequest），并可以通过DOM接口来访问，因此很容易被攻击者利用。
防御HTTP报头追踪漏洞的方法通常禁用HTTP TRACE方法。

五、Struts2远程命令执行漏洞
ApacheStruts是一款建立Java web应用程序的开放源代码架构。Apache Struts存在一个输入过滤错误，如果遇到转换错误可被利用注入和执行任意Java代码。
网站存在远程代码执行漏洞的大部分原因是由于网站采用了Apache Struts Xwork作为网站应用框架，由于该软件存在远程代码执高危漏洞，导致网站面临安全风险。CNVD处置过诸多此类漏洞，例如：“GPS车载卫星定位系统”网站存在远程命令执行漏洞(CNVD-2012-13934)；Aspcms留言本远程代码执行漏洞（CNVD-2012-11590）等。
修复此类漏洞，只需到Apache官网升级Apache Struts到最新版本：http://struts.apache.org

六、文件上传漏洞
文件上传漏洞通常由于网页代码中的文件上传路径变量过滤不严造成的，如果文件上传功能实现代码没有严格限制用户上传的文件后缀以及文件类型，攻击者可通过 Web 访问的目录上传任意文件，包括网站后门文件（webshell），进而远程控制网站服务器。
因此，在开发网站及应用程序过程中，需严格限制和校验上传的文件，禁止上传恶意代码的文件。同时限制相关目录的执行权限，防范webshell攻击。

七、私有IP地址泄露漏洞
IP地址是网络用户的重要标示，是攻击者进行攻击前需要了解的。获取的方法较多，攻击者也会因不同的网络情况采取不同的方法，如：在局域网内使用Ping指令，Ping对方在网络中的名称而获得IP；在Internet上使用IP版的QQ直接显示。最有效的办法是截获并分析对方的网络数据包。攻击者可以找到并直接通过软件解析截获后的数据包的IP包头信息，再根据这些信息了解具体的IP。
针对最有效的“数据包分析方法”而言，就可以安装能够自动去掉发送数据包包头IP信息的一些软件。不过使用这些软件有些缺点，譬如：耗费资源严重，降低计算机性能；访问一些论坛或者网站时会受影响；不适合网吧用户使用等等。现在的个人用户采用最普及隐藏IP的方法应该是使用代理，由于使用代理服务器后，“转址服务”会对发送出去的数据包有所修改，致使“数据包分析”的方法失效。一些容易泄漏用户IP的网络软件(QQ、MSN、IE等)都支持使用代理方式连接Internet，特别是QQ使用“ezProxy”等代理软件连接后，IP版的QQ都无法显示该IP地址。虽然代理可以有效地隐藏用户IP，但攻击者亦可以绕过代理，查找到对方的真实IP地址，用户在何种情况下使用何种方法隐藏IP，也要因情况而论。

八、未加密登录请求
由于Web配置不安全，登陆请求把诸如用户名和密码等敏感字段未加密进行传输，攻击者可以窃听网络以劫获这些敏感信息。建议进行例如SSH等的加密后再传输。

九、敏感信息泄露漏洞
SQL注入、XSS、目录遍历、弱口令等均可导致敏感信息泄露，攻击者可以通过漏洞获得敏感信息。针对不同成因，防御方式不同

十、CSRF
http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html

Web应用是指采用B/S架构、通过HTTP/HTTPS协议提供服务的统称。随着互联网的广泛使用，Web应用已经融入到日常生活中的各个方面：网上购物、网络银行应用、证券股票交易、政府行政审批等等。在这些Web访问中，大多数应用不是静态的网页浏览，而是涉及到服务器侧的动态处理。此时，如果Java、PHP、ASP等程序语言的编程人员的安全意识不足，对程序参数输入等检查不严格等，会导致Web应用安全问题层出不穷。

本文根据当前Web应用的安全情况，列举了Web应用程序常见的攻击原理及危害，并给出如何避免遭受Web攻击的建议。

Web应用漏洞原理
Web应用攻击是攻击者通过浏览器或攻击工具，在URL或者其它输入区域（如表单等），向Web服务器发送特殊请求，从中发现Web应用程序存在的漏洞，从而进一步操纵和控制网站，查看、修改未授权的信息。

1.1 Web应用的漏洞分类
1、信息泄露漏洞

信息泄露漏洞是由于Web服务器或应用程序没有正确处理一些特殊请求，泄露Web服务器的一些敏感信息，如用户名、密码、源代码、服务器信息、配置信息等。

造成信息泄露主要有以下三种原因：

–Web服务器配置存在问题，导致一些系统文件或者配置文件暴露在互联网中；

–Web服务器本身存在漏洞，在浏览器中输入一些特殊的字符，可以访问未授权的文件或者动态脚本文件源码；

–Web网站的程序编写存在问题，对用户提交请求没有进行适当的过滤，直接使用用户提交上来的数据。

2、目录遍历漏洞

目录遍历漏洞是攻击者向Web服务器发送请求，通过在URL中或在有特殊意义的目录中附加“../”、或者附加“../”的一些变形（如“..\”或“..//”甚至其编码），导致攻击者能够访问未授权的目录，以及在Web服务器的根目录以外执行命令。

3、命令执行漏洞

命令执行漏洞是通过URL发起请求，在Web服务器端执行未授权的命令，获取系统信息，篡改系统配置，控制整个系统，使系统瘫痪等。

命令执行漏洞主要有两种情况：

–通过目录遍历漏洞，访问系统文件夹，执行指定的系统命令；

–攻击者提交特殊的字符或者命令，Web程序没有进行检测或者绕过Web应用程序过滤，把用户提交的请求作为指令进行解析，导致执行任意命令。

4、文件包含漏洞

文件包含漏洞是由攻击者向Web服务器发送请求时，在URL添加非法参数，Web服务器端程序变量过滤不严，把非法的文件名作为参数处理。这些非法的文件名可以是服务器本地的某个文件，也可以是远端的某个恶意文件。由于这种漏洞是由PHP变量过滤不严导致的，所以只有基于PHP开发的Web应用程序才有可能存在文件包含漏洞。

5、SQL注入漏洞

SQL注入漏洞是由于Web应用程序没有对用户输入数据的合法性进行判断，攻击者通过Web页面的输入区域(如URL、表单等) ，用精心构造的SQL语句插入特殊字符和指令，通过和数据库交互获得私密信息或者篡改数据库信息。SQL注入攻击在Web攻击中非常流行，攻击者可以利用SQL注入漏洞获得管理员权限，在网页上加挂木马和各种恶意程序，盗取企业和用户敏感信息。

6、跨站脚本漏洞

跨站脚本漏洞是因为Web应用程序时没有对用户提交的语句和变量进行过滤或限制，攻击者通过Web页面的输入区域向数据库或HTML页面中提交恶意代码，当用户打开有恶意代码的链接或页面时，恶意代码通过浏览器自动执行，从而达到攻击的目的。跨站脚本漏洞危害很大，尤其是目前被广泛使用的网络银行，通过跨站脚本漏洞攻击者可以冒充受害者访问用户重要账户，盗窃企业重要信息。

根据前期各个漏洞研究机构的调查显示，SQL注入漏洞和跨站脚本漏洞的普遍程度排名前两位，造成的危害也更加巨大。

1.2 SQL注入攻击原理
SQL注入攻击是通过构造巧妙的SQL语句，同网页提交的内容结合起来进行注入攻击。比较常用的手段有使用注释符号、恒等式（如1＝1）、使用union语句进行联合查询、使用insert或update语句插入或修改数据等，此外还可以利用一些内置函数辅助攻击。

通过SQL注入漏洞攻击网站的步骤一般如下：

第一步：探测网站是否存在SQL注入漏洞。

第二步：探测后台数据库的类型。

第三步：根据后台数据库的类型，探测系统表的信息。

第四步：探测存在的表信息。

第五步：探测表中存在的列信息。

第六步：探测表中的数据信息。

1.3 跨站脚本攻击原理
跨站脚本攻击的目的是盗走客户端敏感信息,冒充受害者访问用户的重要账户。跨站脚本攻击主要有以下三种形式：

1、本地跨站脚本攻击

B给A发送一个恶意构造的Web URL，A点击查看了这个URL，并将该页面保存到本地硬盘（或B构造的网页中存在这样的功能）。A在本地运行该网页，网页中嵌入的恶意脚本可以A电脑上执行A持有的权限下的所有命令。

2、反射跨站脚本攻击

A经常浏览某个网站，此网站为B所拥有。A使用用户名/密码登录B网站，B网站存储下A的敏感信息（如银行帐户信息等）。C发现B的站点包含反射跨站脚本漏洞，编写一个利用漏洞的URL，域名为B网站，在URL后面嵌入了恶意脚本（如获取A的cookie文件），并通过邮件或社会工程学等方式欺骗A访问存在恶意的URL。当A使用C提供的URL访问B网站时，由于B网站存在反射跨站脚本漏洞，嵌入到URL中的恶意脚本通过Web服务器返回给A，并在A浏览器中执行，A的敏感信息在完全不知情的情况下将发送给了C。

3、持久跨站脚本攻击

B拥有一个Web站点，该站点允许用户发布和浏览已发布的信息。C注意到B的站点具有持久跨站脚本漏洞，C发布一个热点信息，吸引用户阅读。A一旦浏览该信息，其会话cookies或者其它信息将被C盗走。持久性跨站脚本攻击一般出现在论坛、留言簿等网页，攻击者通过留言，将攻击数据写入服务器数据库中，浏览该留言的用户的信息都会被泄漏。

Web应用漏洞的防御实现
对于以上常见的Web应用漏洞漏洞，可以从如下几个方面入手进行防御：

1)对 Web应用开发者而言

大部分Web应用常见漏洞，都是在Web应用开发中，开发者没有对用户输入的参数进行检测或者检测不严格造成的。所以，Web应用开发者应该树立很强的安全意识，开发中编写安全代码；对用户提交的URL、查询关键字、HTTP头、POST数据等进行严格的检测和限制，只接受一定长度范围内、采用适当格式及编码的字符，阻塞、过滤或者忽略其它的任何字符。通过编写安全的Web应用代码，可以消除绝大部分的Web应用安全问题。

2) 对Web网站管理员而言

作为负责网站日常维护管理工作Web管理员，应该及时跟踪并安装最新的、支撑Web网站运行的各种软件的安全补丁，确保攻击者无法通过软件漏洞对网站进行攻击。

除了软件本身的漏洞外，Web服务器、数据库等不正确的配置也可能导致Web应用安全问题。Web网站管理员应该对网站各种软件配置进行仔细检测，降低安全问题的出现可能。

此外，Web管理员还应该定期审计Web服务器日志，检测是否存在异常访问，及早发现潜在的安全问题。

3）使用网络防攻击设备

前两种为事前预防方式，是比较理想化的情况。然而在现实中，Web应用系统的漏洞还是不可避免的存在：部分Web网站已经存在大量的安全漏洞，而Web开发者和网站管理员并没有意识到或发现这些安全漏洞。由于Web应用是采用HTTP协议，普通的防火墙设备无法对Web类攻击进行防御，因此可以使用IPS入侵防御设备来实现安全防护。

H3C IPS Web攻击防御

H3C IPS入侵防御设备有一套完整的Web攻击防御框架，能够及时发现各种已经暴露的和潜在的Web攻击。下图为对于Web攻击的总体防御框架。

图1：Web攻击防御框架，参见：http://blog.csdn.net/moshenglv/article/details/53439579

H3C IPS采用基于特征识别的方式识别并阻断各种攻击。IPS设备有一个完整的特征库，并可定期以手工与自动的方式对特征库进行升级。当网络流量进入IPS后，IPS首先对报文进行预处理，检测报文是否正确，即满足协议定义要求，没有错误字段；如果报文正确，则进入深度检测引擎。该引擎是IPS检测的核心模块，对通过IPS设备的Web流量进行深层次的分析，并与IPS攻击库中的特征进行匹配，检测Web流量是否存在异常；如果发现流量匹配了攻击特征，IPS则阻断网络流量并上报日志；否则，网络流量顺利通过。

此Web攻击防御框架有如下几个特点：

1) 构造完整的Web攻击检测模型，准确识别各种Web攻击

针对Web攻击的特点，考虑到各种Web攻击的原理和形态，在不同漏洞模型之上开发出通用的、层次化的Web攻击检测模型，并融合到特征库中。这些模型抽象出Web攻击的一般形态，对主流的攻击能够准确识别，使得模型通用化。

2) 检测方式灵活，可以准确识别变形的Web攻击

在实际攻击中，攻击者为了逃避防攻击设备的检测，经常对Web攻击进行变形，如采用URL编码技术、修改参数等。H3C根据Web应用漏洞发生的原理、攻击方式和攻击目标，对攻击特征进行了扩展。即使攻击者修改攻击参数、格式、语句等内容，相同漏洞原理下各种变形的攻击同样能够被有效阻断。这使得IPS的防御范围扩大，防御的灵活性也显着增强，极大的减少了漏报情况的出现。

3) 确保对最新漏洞及技术的跟踪，有效阻止最新的攻击

随着Web攻击出现的频率日益增高，其危害有逐步扩展的趋势。这对IPS设备在防御的深度和广度上提出了更高的要求，不仅要能够防御已有的Web攻击，更要有效的阻止最新出现的、未公布的攻击。目前，H3C已经建立起一套完整的攻防试验环境，可以及时发现潜在Web安全漏洞。同时还在继续跟踪最新的Web攻击技术和工具，及时更新Web攻击的特征库，第一时间发布最新的Web漏洞应对措施，确保用户的网络不受到攻击。

4) 保证正常业务的高效运行

检测引擎是IPS整个设备运行的关键，该引擎使用了高效、准确的检测算法，对通过设备的流量进行深层次的分析，并通过和攻击特征进行匹配，检测流量是否存在异常。如果流量没有匹配到攻击特征，则允许流量通过，不会妨碍正常的网络业务，在准确防御的同时保证了正常业务的高效运行。

结束语

互联网和Web技术广泛使用，使Web应用安全所面临的挑战日益严峻，Web系统时时刻刻都在遭受各种攻击的威胁，在这种情况下，需要制定一个完整的Web攻击防御解决方案，通过安全的Web应用程序、Web服务器软件、Web防攻击设备共同配合，确保整个网站的安全。任何一个简单的漏洞、疏忽都会造成整个网站受到攻击，造成巨大损失。此外 ，Web攻击防御是一个长期持续的工作，随着Web技术的发展和更新，Web攻击手段也不断发展，针对这些最新的安全威胁，需要及时调整Web安全防护策略，确保Web攻击防御的主动性，使Web网站在一个安全的环境中为企业和客户服务。

原文链接：