（1）SQLインジェクション
原則：いわゆるSQLインジェクションは、クエリ文字列を送信したり、悪質なSQLコマンドを実行するサーバーを欺くために最終的には、SQLコマンドでドメイン名またはページ要求を入力されたWebフォームに挿入されています。具体的には、既存のアプリケーションの使用があり、実行のバックエンドデータベースエンジンの能力に（悪質な）SQLコマンドインジェクションが、それはセキュリティ上の脆弱性のサイト上で取得するには、Webフォームで（悪質な）SQL文を入力することができますデザイナーの意図に基づいてSQL文を実行するデータベースではなく、。二つの理由のためにSQLインジェクションが生じる：一方が濾過されていない（入力フィルタ）入力データ、逃れるために送信されるデータのないデータベースは、（出力をエスケープ）があります。
リハビリテーションプログラム：これは、コード内でデジタル変換タイプにパラメータのデジタルタイプのために推奨して、SQLクエリステートメントに代入され、そのような行動は、任意の成功を注入することはできません。そして、このようなクエリを取得するSQL言語のためのいくつかのパラメータとPOSTパラメータとしてフィルタリングパラメータを、考えます。したがって、ユーザーの入力を防止する必要性をチェックするとき。このような単一および二重引用符、セミコロン、コンマ、コロン等の特殊式の特殊文字、濾過によって接続IDなどを変換します。
（2）認証の失敗とセッション管理を
原理：認証とセッション管理アプリケーション機能に関連することが多い適切に攻撃者で、その結果、実装されていないパスワード、キー、セッショントークンや実装上の問題を破壊することができ、他のユーザーの身元を引き受けます
リハビリテーションプログラム：エントリ認定挨拶の組み込みのセッション管理機能2. 3.を使用して1つの点4はSSLで保護されたページログイン初めに確認してください
（3）クロスサイトスクリプティングのXSS
原則：クロスサイトスクリプティング攻撃の英語名は、クロスサイトスクリプトで、スタイルシートはXSSと略す、差別化します。何が起こるかというと、ウェブサイトは、潜在的に悪質なコードがブラウザを実行する過程で、出力にユーザーがページの内容を入力することになるということです。クロスサイトスクリプティング攻撃htmlコード内のWebを埋め込まれたページを閲覧するユーザーは、悪意のあるユーザーの特定の目的を達成するために実行されるとき、それは、htmlコードに悪意のあるWebページを挿入するには、悪意のある攻撃者を指します。XSSは、多くの場合、彼らはほとんど害を呼び出すために、受動的と非常に多くの人々のその貧弱な使用の攻撃のパッシブ型です。紙は、XSSの使用は、ターゲット・サーバーのシェルを得ることを強調しています。技術は古い技術ですが、アイデアは、我々は手助けをしたいが。三つの方法でXSS脆弱性が知られている：1）に格納2）反射; 3）DOMに基づきます。
1は、ファンクションポイント蓄積型クロスサイトスクリプティング攻撃が関与：データベースにユーザーが入力したテキスト情報を保存し、そして、そのようなユーザーのコメントなどの表示ページの時点で機能することができ、駅を送って、そのような機能のポイントとして、個人情報を変更します。
2、ファンクションポイント、反射、クロスサイトスクリプティング攻撃が関与：URLパラメータが必要とされ、このようなサイトの検索などのページ表示機能ポイントでの反射、クロスサイトスクリプティング攻撃があるかもしれない、クエリ機能を指します。
3は、ファンクションポイントDOM XSS攻撃をもとに関与：（これらに限定されない）を含め、DOMオブジェクトのページプログラムを必要とします：
| document.URL document.URLUnencoded document.location document.referrer window.locationの |
リハビリテーションプログラム：一般的な修理方法は：すべての入力データは、効果的な攻撃を検出することを確認し、適切に任意のスクリプトが正常にブラウザで実行を移植された防ぐために、すべての出力データを符号化します。次のように：
図1に示すように、入力検証：データは、すべての入力データを標準入力認証長さを検証するメカニズム、タイプ、構文、およびビジネス・ルールを使用して、格納され又は表示される前に受け入れられるようになります。
図2に示すように、出力コード：データ出力の前に、ユーザエンティティによって送信されたデータが正しく、サブセットだけに限定されないすべての文字をエンコードすることが推奨され、符号化された行われたことを確認してください。
3、明示的に出力エンコーディングを指定：攻撃者がユーザーのために（例えばISO 8859-1やUTF-8など）のエンコードを選択することができないでください。
4、認証の制限をブラックリストに注意を払う：だけ見つけるか（例えば、「<」、「>」または同様の「スクリプト」をキーワードとして）一部の文字を置換し、認証機構のXSS攻撃のバリエーションをバイパスすることは容易です。
図5に示すように、正規化誤差の警戒：入力検証、標準化および現在の内部アプリケーションの表現に適合するためにデコードされなければなりません。アプリケーションは、同じ入力復号化のために二度ではないことを確認してください。クライアントフィルタによって提出されたデータは、一般的な二重引用符として二重引用符（「）、角括弧（<、>）、およびクライアントに含まれるエンティティの変換、によって提出された他の特殊文字や特殊文字のデータをフィルタリングすることをお勧めします（「）は、実際の形に変換される＆QUOT ;, <物理的形態が対応する＆LT ;, <物理的形態が対応＆GT;以下をフィルタリングするための一般的な文字です。
| [1] |（パイプ記号） [2]＆（アンパサンド） [3];（セミコロン） [4] $（ドル記号） [5]％（パーセント記号） （アットマーク）[6] @ [7]「（一重引用符） [8]「（引用） [9] \「（バックスラッシュシングルクォート） [10] \「（バックスラッシュエスケープ引用符） 〔11〕<>（角括弧） [12]（）（カッコ） [13] +（プラス） [14] CR（キャリッジリターン、ASCIIの0x0Dの） [15] LF（ラインフィード、ASCII文字は0x0A） [16]、（カンマ） [17] \（バックスラッシュ） 2は、戻るキー文字への要求にエスケープ。 [1]「（二重引用符）：＆QUOT [2]「（単一引用符）：＆APOS [3]＆（アンド符号）：＆アンプ [4] <（左アングルブラケット）：＆LT [5]>（右アングルブラケット）：＆GT 前提のアプリケーションへの偏見がなければ、TRACEメソッドを無効にしながら、クッキーは、HTTPのみをマークお勧めします。 |
安全でないオブジェクトへの（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当中获取登录信息，然后判断