(1)SQL 注入
原理：所谓SQL注入，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。 造成SQL注入漏洞原因有两个：一个是没有对输入的数据进行过滤（过滤输入），还有一个是没有对发送到数据库的数据进行转义（转义输出）。
修复方案：建议在代码中对数字类型的参数先进行数字类型变换，然后再代入到SQL查询语句中，这样任何注入行为都不能成功。并且考虑过滤一些参数，比如get参数和post参数中对于SQL语言查询的部分。所以防范的时候需要对用户的输入进行检查。特别式一些特殊字符，比如单引号，双引号，分号，逗号，冒号，连接号等进行转换或者过滤。
(2)失效的身份认证和会话管理
原理：与认证和会话管理相关的应用程序功能往往得不到正确实施，导致了攻击者可以破坏密码，密钥，会话令牌或实施漏洞冒充其他用户身份
修复方案：1.使用内置的会话管理功能 2.通过认证的问候 3.使用单一的入口点 4.确保在一开始登录SSL保护的网页
(3)跨站脚本攻击 XSS
原理：跨站脚本攻击的英文全称是Cross Site Script，为了和样式表区分，缩写为XSS。发生的原因是网站将用户输入的内容输出到页面上，在这个过程中可能有恶意代码被浏览器执行。跨站脚本攻击,它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。XSS属于被动式的攻击，因为其被动且不好利用，所以许多人常呼略其危害性。而本文主要讲的是利用XSS得到目标服务器的shell。技术虽然是老技术，但是其思路希望对大家有帮助。已知的跨站脚本攻击漏洞有三种：1）存储式；2）反射式；3）基于DOM。
1、 存储型跨站脚本攻击涉及的功能点：用户输入的文本信息保存到数据库中，并能够在页面展示的功能点，例如用户留言、发送站内消息、个人信息修改等功能点。
2、 反射型跨站脚本攻击涉及的功能点：URL参数需要在页面显示的功能点都可能存在反射型跨站脚本攻击，例如站内搜索、查询功能点。
3、 基于DOM跨站脚本攻击涉及的功能点：涉及DOM对象的页面程序，包括（不限这些）：
| document.URL document.URLUnencoded document.location document.referrer window.location |
修复方案： 总体修复方式：验证所有输入数据，有效检测攻击；对所有输出数据进行适当的编码，以防止任何已成功注入的脚本在浏览器端运行。具体如下 ：
1、 输入验证：某个数据被接受为可被显示或存储之前，使用标准输入验证机制，验证所有输入数据的长度、类型、语法以及业务规则。
2、 输出编码：数据输出前，确保用户提交的数据已被正确进行entity编码，建议对所有字符进行编码而不仅局限于某个子集。
3、 明确指定输出的编码方式：不要允许攻击者为你的用户选择编码方式(如ISO 8859-1或 UTF 8)。
4、 注意黑名单验证方式的局限性：仅仅查找或替换一些字符(如"<" ">"或类似"script"的关键字)，很容易被XSS变种攻击绕过验证机制。
5、 警惕规范化错误：验证输入之前，必须进行解码及规范化以符合应用程序当前的内部表示方法。请确定应用程序对同一输入不做两次解码。对客户端提交的数据进行过滤，一般建议过滤掉双引号（”）、尖括号（<、>）等特殊字符，或者对客户端提交的数据中包含的特殊字符进行实体转换，比如将双引号（”）转换成其实体形式"，<对应的实体形式是<，<对应的实体形式是>以下为需过滤的常见字符：
| [1] |（竖线符号） [2] & （& 符号） [3];（分号） [4] $（美元符号） [5] %（百分比符号） [6] @（at 符号） [7] '（单引号） [8] "（引号） [9] \'（反斜杠转义单引号） [10] \"（反斜杠转义引号） [11] <>（尖括号） [12] ()（括号） [13] +（加号） [14] CR（回车符，ASCII 0x0d） [15] LF（换行，ASCII 0x0a） [16] ,（逗号） [17] \（反斜杠） 2、在请求返回页面关键字符进行转义； [1] “（双引号）：" [2] ’ （单引号）：&apos [3] &（&符号）：& [4] <（左尖括号）：< [5] >（右尖括号）：> 在不影响应用的前提下，建议将cookie标记为httpOnly，同时禁用TRACE方法。 |
(4)直接引用不安全的对象
原理：指一个已经授权的用户通过更改访问时的参数，从而访问到原本其并没有得到授权的对象。
修复方案：
1.使用基于用户或会话的间接对象访问，这样可防止攻击者直接攻击为授权资源
2.访问检查：对任何来自不受信源所使用的所有对象进行访问控制检查
3.避免在url或网页中直接引用内部文件名或数据库关键字
4.验证用户输入和url请求，拒绝包含./ ../的请求
(5)安全配置错误
原理：安全配置错误可以发生在一个应用程序堆栈的任何层面，包括平台，web服务器，应用服务器，数据库，架构和自定义的代码。攻击者通过访问默认账户，未使用的网页，未安装的补丁的漏洞，未被保护的文件和目录等，以获得对系统为授权的访问
修复方案：
1.自动化安装部署
2.及时了解并部署每个环节的软件更新和补丁信息
3.实施漏洞扫描和安全审计
(6)敏感信息泄露
原理：由于管理员或者技术人员等各种原因导致敏感信息泄露
修复方案：1.对信息加密 2.强化安全意识
(7)缺少功能级的访问控制
原理：这个漏洞也是与认证相关的，这种漏洞具体是指在系统已经对url的访问做了限制的情况下，但这种限制并没有生效。常见的例子是系统没有对用户进行角色的检查，以及用户通过修改URL的action并指向未被授权页面就能访问该页面同样是个漏洞
修复方案：
1.检查管理权限的过程并确保能够容易进行升级和审计
2.默认缺省情况下，应该拒绝所有访问的执行权限。对于每个功能得访问，需要明确的角色授权
3.检查每个功能分配的权限合理有效
(8)跨站请求伪造 CSRF
原理：跨站请求伪造攻击，Cross-Site Request Forgery（CSRF），攻击者在用户浏览网页时，利用页面元素（例如img的src），强迫受害者的浏览器向Web应用服务器发送一个改变用户信息的HTTP请求。CSRF攻击可以从站外和站内发起。从站内发起CSRF攻击，需要利用网站本身的业务，比如“自定义头像”功能，恶意用户指定自己的头像URL是一个修改用户信息的链接，当其他已登录用户浏览恶意用户头像时，会自动向这个链接发送修改信息请求。从站外发送请求，则需要恶意用户在自己的服务器上，放一个自动提交修改个人信息的htm页面，并把页面地址发给受害者用户，受害者用户打开时，会发起一个请求。威胁描述：攻击者使用CSRF攻击能够强迫用户向服务器发送请求，导致用户信息被迫修改，甚至可引发蠕虫攻击。如果恶意用户能够知道网站管理后台某项功能的URL，就可以直接攻击管理员，强迫管理员执行恶意用户定义的操作。
修复方案：
1、 通过referer判断页面来源进行CSRF防护，该方式无法防止站内CSRF攻击及referer字段伪造。
2、 重要功能点使用动态验证码进行CSRF防护。
3、 通过token方式进行CSRF防护：
|
1、 在Session中绑定token。如果不能保存到服务器端Session中，则可以替代为保存到Cookie里。 2、 在form表单中自动填入token字段，比如 <input type=hidden name="anti_csrf_token" value="$token" />。 3、 在HTTP请求中自动添加token。 在服务器端对比POST提交参数的token与Session中绑定的token是否一致，以验证CSRF攻击 |
(9)使用含有已知漏洞的组件
原理：应用程序使用带有已知漏洞的组件会破坏应用程序防御系统，可能导致严重的数据丢失或服务器接管
修复方案：
1.识别正在使用的组件和版本，包括所有的依赖
2.更新组件或引用的库文件到最新
3.建立安全策略来管理组件的使用
(10）未验证的重定向和转发
原理：在Web应用中重定向是极为普通的，并且通常重定向所引发的目的是带有用户输入参数的目的url，而如果这些重定向未被验证，那么攻击者就可以引导用户访问他们想要用户访问的站点。同样，转发也是极为普遍的，本质上转发是在同一个应用中对一个新页面发送请求，并且有时是用参数来定义目标页面的。同样，如果参数未被验证，那么攻击者就可以利用其来绕过认证或是授权检查
修复方案：
1.避免使用重定向和转发
2.如果使用了，不要在确定目标时涉及到用户参数
3.如果无法避免使用用户参数，则应确保目标参数值对于当前用户是有效的并已授权
如果是需要登录的，可以从session当中获取登录信息，然后判断