随着Web2.0、网络社交等一系列新型的互联网产品的诞生，基于Web环境的互联网应用越来越广泛，企业信息化的过程中，越来越多的应用都架设在Web平台上。Web业务的迅速发展吸引了黑客们的强烈关注，接踵而至的就是Web安全威胁的凸显。黑客利用网站操作系统的漏洞和Web服务程序的SQL注入漏洞等得到Web服务器的控制权限，轻则篡改网页内容，重则窃取重要内部数据，更为严重的则是在网页中植入恶意代码，使得网站访问者受到侵害。这使得越来越多的用户关注应用层的安全问题，Web应用安全的关注度也逐渐升温。
------本文目录------
SQL注入：
XSS跨站脚本攻击
CSRF跨站请求伪造
任意文件读取：
任意代码执行：
越权访问：
敏感信息泄露：
越权访问
不安全的会话管理漏洞
用户名/口令暴力爆破：
弱口令漏洞：
撞库攻击：
注册模块设计缺陷：
短信接口设计缺陷：
URL重定向漏洞：
DDOS拒绝服务漏洞
不足的日志记录和监控：
业务逻辑漏洞：
网络安全通信协议：
一、SQL注入：
SQL注入（SQL Injection），是一个常见的发生于应用程序和数据库之间的web安全漏洞，由于在开发过程中的设计不当导致程序中忽略了检查，没有有效的过滤用户的输入，是攻击者可以向服务器提交不正常的访问数据（即恶意的SQL命令代码），程序在接收后错误的将攻击者的输入作为代码语句的一部分执行，导致原始的查询逻辑被改变，额外的执行了攻击者静态构造的恶意代码，从而绕过验证机制和权限检查，达到取得隐藏数据或覆盖关键的参值，甚至执行数据库主机操作系统命令的目的。
SQL注入危害
数据库信息泄露：数据库中存放的用户的隐私信息的泄露
网页篡改：通过操作数据库对特定网页进行篡改
网站被挂马，传播恶意软件：修改数据库一些字段的值，嵌入网页链接，进行挂马攻击。
数据库被恶意操作：数据库服务器被攻击，数据库的系统管理员账户被篡改。
服务器被远程控制，被安装后门。经由数据库服务器提供的操作系统支持，让黑客得以修改或控制操作系统。
破坏硬盘数据，瘫痪全系统。
例子：
应对方案：
过滤特殊字符：单引号、双引号、斜杠、反斜杠、冒号、空字符等的字符
过滤的对象：用户的输入；提交的URL请求中的参数部分；从cookie中得到的数据；部署方SQL注入系统或脚本。
严格限制web应用的数据库的操作权限，给用户提供仅能满足需求的最低权限，从而最大限度的减少注入攻击对数据库的危害。
对进入数据的特殊字符（‘ “ \ <> & *）进行转义处理（或编码转换）
不要直接拼接SQL语句，所有的查询语句建议使用数据库提供的参数化查询接口，使用参数化的语句而不是将用户输入的变量嵌入SQL语句中。
在应用发布之前建议使用专业的SQL注入检测工具进行检测，及时修补被检测出的SQL注入漏洞。
避免网站打印SQL错误信息，比如类型错误、字段不匹配等，可对异常信息做封装，给出友好提示，不直接打印堆栈信息到前端。
二、XSS跨站脚本攻击：
跨站脚本漏洞（Cross-site scripting , xss），是一种常见的web安全漏洞，由于web应用未对用户提交的数据做充分的检查过滤，允许用户在提交的数据中掺入HTML代码（最主要的是”>”,”<”），并将未经转义的恶意代码输出到第三方用户的浏览器解释执行，从而导致XSS漏洞。攻击成功后，攻击者可以得到更高的权限、私密网页内容、会话和cookie等内容。
XSS类型包括：
（1）非持久型跨站：即反射型跨站脚本漏洞，是目前最普遍的跨站类型。跨站代码一般存在于链接中，请求这样的链接时，跨站代码经过服务端反射回来，这类跨站的代码不存储到服务端（比如数据库中）。
（2）持久型跨站：这是危害最直接的跨站类型，跨站代码存储于服务端（比如数据库中）。常见情况是某用户在论坛发贴，如果论坛没有过滤用户输入的Javascript代码数据，就会导致其他浏览此贴的用户的浏览器会执行发贴人所嵌入的Javascript代码。
（3）DOM跨站（DOM XSS）：是一种发生在客户端DOM（Document Object Model文档对象模型）中的跨站漏洞，很大原因是因为客户端脚本处理逻辑导致的安全问题。
应对方案：
1、与SQL注入防护的建议一样，假定所有输入都是可疑的，必须对所有输入中的script、iframe等字样进行严格的检查。这里的输入不仅仅是用户可以直接交互的输入接口，也包括HTTP请求中的Cookie中的变量，HTTP请求头部中的变量等。
2、不仅要验证数据的类型，还要验证其格式、长度、范围和内容。
3、针对请求参数以及用户可控数据进行防御，对输出进行编码处理。
4、在服务端对每一个输入进行合法性验证，只允许输入常见符号，字母以及数字。
5、对Cookie添加HttpOnly标识。
三、CSRF跨站请求伪造：
跨站请求伪造（Cross-site request forgery , CSRF），是一种常见的web安全漏洞，由于在web请求中重要操作的所有参数可被猜测到，攻击者可通过一些技术手段欺骗用户的浏览器去访问一个用户曾经认证过的网站，遂使攻击者可冒用用户的身份，进行恶意操作。
应对方案：
1、在表单中添加一个随机的数字或字母验证码，通过强制用户和应用进行交互，来有效地遏制CSRF攻击。
2、如果检查发现是非正常页面提交的请求（根据Referer进行判断），则极有可能是CSRF攻击。
3、在请求的参数里增加一个随机的token参数，且不可被猜测。
4、敏感的操作应该使用POST，而不是GET，以form表单的形式提交，可以避免token泄露。
四、任意文件读取：
任意文件读取漏洞（Unrestricted File Upload），是一种常见的web安全漏洞，因web程序提供的文件查看下载、附件下载等功能存在安全缺陷，导致通过修改该文件路径就能够查看和下载任意文件，这些文件包括：源代码文件、系统文件（/etc/passwd , C:/boot.ini等）、配置文件（config.php , /WEB-INF/web.xml , web.config等），造成网站敏感信息泄露，严重危害网站安全。
应对方案：
1、服务端过滤特殊字符。（…./、 ….\、 ….\）
2、判断用户输入的参数的格式是否合法。
3、指定文件类型白名单（如：jpg\gif\png\rar\zip\pdf\doc\xls\ppt等），禁止用户读取、下载白名单以外的文件。
4、指定下载路径，禁止用户读取、下载指定目录以外的文件。
五、任意代码执行：
任意代码执行漏洞（Unrestrcted Code Execution），是一种常见的web安全漏洞，由于web程序没有针对执行函数做过滤，当web程序应用在调用一些能将字符串转化成命令的函数（如PHP中的eval(),system(),exec()）时，没有考虑做一些安全限制，导致可以通过构造特殊代码，执行操作系统命令，致使攻击者获取到网站服务器权限。
应对方案：
1、如果因使用的框架或中间件造成远程代码执行漏洞，需及时升级框架和中间件。
2、针对代码中可执行的特殊函数入口进行过滤，尝试对所有提交的可能执行命令的语句进行严格的检查或者对外部输入进行控制，系统命令执行函数，不允许传递外部参数。
3、所有的过滤步骤要在服务器进行，不仅要验证数据的类型，还要验证期格式、长度、范围和内容。
六、任意文件上传：
任意文件上传（Unrestricted File Upload），是一种常见的web安全漏洞，由于web应用程序在实现文件上传功能是对上传的文件缺少必要的检查，使得攻击者可上传任意文件。利用该漏洞，攻击者可以直接上传webshell（webShell 就是以asp\php\jsp或者cgi等网页文件形式存在的一种命令执行环境，也可以将其称之为一种网页后门）、病毒、恶意脚本等各种危险文件，可能导致服务器权限被直接获取，从而危及整个系统的安全运行。
应对方案：
1、对用户上传的文件后缀采用白名单进行限制，且重命名文件名。
2、限定文件上传目录，且该目录不允许解析动态脚本文件。
七、敏感信息泄露：
在最近几年，这是最常见的、最具影响力的攻击。这个领域最常见的漏洞是不对敏感信息进行加密。在数据加密过程中，常见的问题是不安全的密钥生成和管理以及使用弱加密算法、弱协议和弱密码。特别是使用弱的哈希算法来保护密码。
攻击者不是直接攻击密码，而是在传输过程中或从客户端（例如：浏览器）窃取密钥、发起中间人攻击，或从服务器端窃取明文数据。
应对方案：
1.应对敏感信息进行强加密再传输的操作，禁止一切敏感信息的明文传输，如：密码明文传输等。
2.对于配置文件的明文存储，可以使用 jasypt 进行密钥加密存储，增强安全性。
八、越权访问：
越权访问（Broken Access Control , BAC），是一种常见的web安全漏洞，这类漏洞是指应用在检查授权（Authorization）时存在纰漏，使得攻击者可以利用一些方式绕过权限检查，访问或者操作到原本无权访问的界面。在实际的代码安全审查中，这类漏洞往往很难通过工具进行自动化检测，因此在实际应用中危害很大。
应对方案：
1、将用户身份标识存在session中并验证，不能把用户身份标识以参数形式置于HTTP请求中，应该放在session中，并且仅通过session验证用户身份。
2、禁止从Cookie参数中去判断用户所属用户组，应该通过读取session会话来判断用户所属用户组。
3、文件下载时，禁止采用可被猜测的连续ID为参数进行文件下载，下载文件时也应判断当前用户是否有权限下载目标文件。
4、非普通用户操作页面严格做好权限管理，增删改查操作需要验证当前用户权限。
九、不安全的会话管理漏洞：
token值信息直接在GET请求的URL上，造成token值的直接暴露，容易被日志记录、搜索引擎等缓存，影响客户会话安全。
应对方案：
禁止token以GET方式传递，可从header中获取。
十、用户名/口令暴力爆破：
用户名/口令爆破（Brute-force attack），是一种常见的web安全漏洞，由于用户登录模块缺少必要的防护机制，使用网站的注册或登录接口，攻击者通过系统地组合所有可能性（例如登录时用到的账户名、密码等），并以穷举法尝试所有可能性破解用户的账户名、密码等敏感信息。
应对方案：
1、增强验证码机制，为防止验证码被破解，可以适当怎加验证码生成的强度，例如中文图形验证码。
2、用户名或密码输入错误均提示“用户名或密码错误”，防止黑客获取到注册用户的信息。
3、限制用户登录失败次数。
4、限制一定时间内IP登录失败次数。
5、限制一系列验证码的使用次数，用完即失效。
十一、弱口令漏洞：
弱口令(weak password)，没有严格和准确的定义，通常认为容易被别人（他们有可能对你很了解）猜测到或被破解工具破解的口令均为弱口令，如：生日、名字、简单的顺序数字or字符。
应对方案：
增强口令复杂度，验证码类可增加生成强度；密码类可增加密码的复杂度。
1、不使用空口令或系统缺省的口令，这些口令众所周之，为典型的弱口令。
2、口令长度不小于8个字符。
3、口令应该为以下四类字符的组合，大写字母(A-Z)、小写字母(a-z)、数字(0-9)和特殊字符。每类字符至少包含一个。如果某类字符只包含一个，那么该字符不应为首字符或尾字符。
十二、撞库攻击：
撞库攻击（Information Leakage Thinking Library Collision），是一种常见的针对web应用的攻击方式，为了方便记忆很多用户在不同网站使用的同一账号和密码，黑客通过收集网络已泄露的拖库信息，特别是注册用户和密码信息，生成对应的字典表，尝试批量自动登陆其它网站验证后，得到一系列可以登录的真实账户。
应对方案：
1、增强验证码机制，为防止验证码被破解，可以适当增加验证码生成的强度，例如中文图形验证码。
2、自动识别异常IP，对于异常IP，整理一个非常严格的恶意IP库，甚至禁止这些IP访问网站。
3、用户账户被撞开后的保护，对用户行为进行分析，如判断用户的登录IP是否在常用地区，如果不是则直接锁定账号，让用户通过收集、邮箱等手段来解锁。
十三、注册模块设计缺陷：
注册模块设计缺陷（Registration module design flaws），是一种常见的web安全漏洞，网站注册模块的设计缺陷将导致一下几点安全漏洞：
1、任意用户密码找回。
2、暴力枚举网站已注册用户。
3、暴力破解用户密码。
4、万能密码登录。
5、SQL注入。
以上安全问题会带来用户密码被盗、个人信息泄露、网站数据库泄露、网站被入侵等风险。
应对方案：
1、如果使用邮件验证的方式找回密码，重置密码令牌需要设置为不可猜测，且加密令牌时使用通过加密的方式，而不是自己构造；设置重置密码会话过期时间，在重置密码时不要从请求中获取需要重置的用户名。
2、如果使用短信验证的方式找回密码，验证短信最少应为6位，且短信过期时间不能超过10分钟，在发送短信页面添加经过混淆过的图形验证码，并在后端设置单位时间内的短信发送频率。
3、限制单位时间内认证错误次数。
4、在用户注册页面、登录界面，添加可靠的机器人识别功能，例如图形验证码或短信验证码。
十四、短信接口设计缺陷：
短信接口设计缺陷（SMS interface design flaws），是一种常见的web安全漏洞，短信接口通常用于注册验证、登录验证及其他敏感操作的验证上，但由于设计不当，通常会导致以下安全问题：
1、短时间内发送大量的手机短信。
2、短信验证码过短易被猜测。
3、短信验证码在发送多次时，多个验证码同时有效。
4、短信验证码在HTTP相应包中返回客户端。
应对方案：
1、在发送短信接口设置机器人识别机制，例如经过混淆的图形验证码，在验证通过后方可发送手机短信。
2、用来验证的验证码短信最少应为6位，过期时间内只能有一个验证码有效，且有效时间不应超过10分钟。
3、不要把短信验证码返回到客户端。
4、短信验证码在认证一次后应立即失效，输入错误需再次获取。
十五、URL重定向漏洞：
URL重定向漏洞（URL redirection vulnerability），是一种常见的web安全漏洞，由于网站URL重定向功能设计不当，没有验证跳转的目标URL是否合法，用户可通过此漏洞转到任意网站，这会导致可通过该网站跳转到存在木马、病毒的网站或者钓鱼网站。
应对方案：
1、不应从用户请求或填写的内容中获取跳转的目标URL，应在后端设定跳转URL。
2、对需要跳转的目标URL进行验证，如果跳转的URL不是所允许的，则禁止跳转。
3、进行URL时提示用户并显示跳转的目标URL地址并询问是否跳转。
十六、DDOS拒绝服务漏洞：
拒绝服务攻击（denial-of-service attack , DOS），亦称“洪水攻击”，是一种网络攻击手段，其目的在于使目标电脑的网络或系统资源耗尽，使服务暂时中断或停止，导致其正常用户无法访问。
拒绝服务的攻击也可能导致与目标计算机同一网络中的其它计算机被攻击。互联网和局域网之间的带宽会被攻击并导致大量消耗，不但影响目标计算机，同时也影响局域网中的其他计算机。如果攻击的规模较大，整个地区的网络连接都可能会受到影响。
一种服务需要面向大众就需要提供用户访问接口，这些接口恰恰就给了黑客有可乘之机，如：可以利用 TCP/IP 协议握手缺陷消耗服务端的链接资源，可以利用 UDP 协议无状态的机制伪造大量的 UDP 数据包阻塞通信信道…… 可以说，互联网的世界自诞生之日起就不缺乏被 DDoS 利用的攻击点，从 TCP/IP 协议机制到 CC、DNS、NTP 反射类攻击，更有甚者利用各种应用漏洞发起更高级更精确的攻击。
1、资源消耗类攻击
资源消耗类是比较典型的 DDoS攻击，最具代表性的包括：Syn Flood、Ack Flood、UDP
Flood。这类攻击的目标很简单，就是通过大量请求消耗正常的带宽和协议栈处理资源的能力，从而达到服务端无法正常工作的目的。
Syn Flood：SYN- Flood 攻击是当前网络上常见的 DDoS 攻击，它就是利用了 TCP 协议实现上的一个缺陷，通过向网络服务所在端口发送大量 的伪造源地址的攻击报文，就可能造成目标服务器中的半开连接队列被占满，从而阻止其他合法用户进行访问。这种攻击早在 1996 年就被发现，但至今仍然显示 出强大的生命力。很多操作系统，甚至防火墙、路由器都无法有效地防御这种攻击，而且由于它可以方便地伪造源地址，追查起来非常困难。它的数据包特征通常 是，源发送了大量的 SYN 包，并且缺少三次握手的最后一步握手 ACK 回复。
Syn Flood原理：攻击者首先伪造地址对 服务器发起 SYN 请求，服务器回应 (SYN+ACK) 包，而真实的 IP 会认为，我没有发送请求，不作回应。服务 器没有收到回应，这样的话，服务器不知 道 (SYN+ACK) 是否发送成功，默认情况下会重试 5 次（tcp_syn_retries）。这样的话，对于服务器的内存，带宽都有很大的消耗。攻击者 如果处于公网，可以伪造 IP 的话，对于服务器就很难根据 IP 来判断攻击者，给防护带来很大的困难。
2、服务消耗性攻击
相比资源消耗类攻击，服务消耗类攻击不需要太大的流量，它主要是针对服务的特点进行精确定点打击，如 web 的 CC，数据服务的检索，文件服务的下载等。这类攻击往往不是为了拥塞流量通道或协议处理通道，它们是让服务端始终处理高消耗型的业务的忙碌状态，进而无法对正常业务进行响应
web 的CC攻击：当一个网页访问的人数特别多的时候，打开网页就慢了，CC 就是模拟多个用户，多少线程就是多少用户，不停地进行访问那些需要大量数据操作，就是需要大量 CPU 时间的页面，造成服务器资源的浪费，CPU 长时间处于 100%，永远都有处理不完的连接直至就网络拥塞，正常的访问被中止。
应对方案：
拒绝服务攻击的防御方式通常为入侵检测，流量过滤和多重验证，意在堵塞网络带宽的流量将被过滤，而正常的流量可正常通过。
1、网络设备：防火墙可以设置规则，例如允许或拒绝特定通讯协议、端口或IP地址。当攻击从少数不正常的IP地址发出时，可以简单的使用拒绝规则阻止一切从攻击源IP发出的通信。
2、黑洞引导/流量清洗：黑洞引导指将所有受攻击计算机的通信全部发送至一个“黑洞”（空接口或不存在的计算机地址）或者有足够能力处理洪流的网络运营商，以避免网络受到较大影响。当流量被送到DDoS防护清洗中心时，通过采用抗DDoS软件处理，将正常流量和恶意流量区分开。这样一来可保障站点能够正常运作，处理真实用户访问网站带来的合法流量。
3、web服务器：升级web服务器，避免出现拒绝服务漏洞，如HTTP.sys（MS15-034）。
十七、不足的日志记录和监控：
对不足的日志记录及监控的利用几乎是每一个重大安全事件的温床。攻击者依靠监控的不足和响应的不及时来达成他们的目标而不被知晓。
根据行业调查的结果，此问题被列入了Top10。判断你是否有足够监控的一个策略是在渗透测试后检查日志。测试者的活动应被充分的记录下来，能够反映出他们造成了什么样的影响。
多数成功的攻击往往从漏洞探测开始。允许这种探测会将攻击成功的可能性提高到近100%；据统计，在2016年确定一起数据泄露事件平均需要花191天时间，这么长时间里损害早已发生。
应对方案：
建议应用系统开启审计功能，审计覆盖所有用户审计日志至少包括用户的注册、登录、关键业务操作等行为进行日志记录，内容包括但不限于用户姓名、手机号码、注册时间、注册地址、登录时间、登录地址、操作用户信息、操作时间、操作内容及操作结果等；
十八、业务逻辑漏洞：
业务逻辑问题是一种设计缺陷，逻辑缺陷表现为设计者或开发者在思考过程中做出的特殊假设存在明显或隐含的错误。攻击者会特别注意目标应用程序采用的逻辑方式，设法了解设计者与开发者做出的可能假设，然后考虑如何攻破这些假设。攻击者挖掘逻辑漏洞有两个重点：业务流程、http/https请求篡改。
业务逻辑漏洞经常出现的场景为：账户（注册/登录/密码找回）、交易、支付、个人信息修改。
应对方案：
应用系统在开发之前，尽量避免设计的缺陷，将容易出现重要业务逻辑漏洞的场景多做思考与设计，利用多场景的用例推敲是否存在漏洞。
十九、网络安全通信协议：
系统在数据传输过程中不具有保护其完整性的措施，通常讲的就是http的网络通讯协议，在此协议下会产生传输数据以明文形式显示，无法保护数据的完整性。
应对方案：
建议使用HTTPS安全网络通讯协议，通过SSL或TLS提供加密处理数据、验证对方身份以及数据完整性保护。
此外，再将几个比较常见的安全规范，如下。
预警级别安全规范：
1.管理后台泄漏漏洞
管理后台的帐号和密码设计过于简单，容易被猜测到，导致攻击者>可以暴力破解帐号密码。
应对方案：
将管理后台的服务绑定到内网ip上，禁止开放在外网。
如果该管理后台必须提供给外网访问，则未登录页面不要显示过多内容，防止敏感信息泄漏，登录帐号需经过认证，且密码设置规则尽量复杂，增加验证码，以防止暴力破解。
2.错误详情泄漏漏洞
页面含有CGI处理错误的代码级别的详细信息，例如sql语句执行错误原因，php的错误行数等。
检测方法：修改参数为非法参数，看页面返回的错误信息是否泄漏了过于详细的代码级别的信息。
应对方案：
将错误信息对用户透明化，在CGI处理错误后可以返回友好的提示语以及返回码。但是不可以提示用户出错的代码级别的详细原因。
3.资源控制
应用系统未对单个账户的多重并发会话进行限制，会出现同个账户，多个操作人同时在操作。
应对方案：
可根据业务系统的需求定制会话的限制数量，类似：同个账户在不同地方登录时提示账户已登录，提供踢出操作，同时提示被踢出用户。
