Webセキュリティ、一般的な攻撃防止

Webセキュリティ

Webセキュリティ

データベースセクション

特定ユーザ

に固定権限を解放する.

ビュー

を使用

mysql注入防止

暗号sha 1加塩暗号化

robotstxt

認証および権限制御

XSS攻撃を防ぐ

CSRF攻撃防止

フィールド検証

phpiniのセキュリティ構成

データベースセクション
1.特定のユーザに対して一定の権限を解放する.

 grant all on *.* to 'username'@'%' identified by 'password';

権限:all:すべての権限;select:クエリー権限

ライブラリ名:*:すべてのライブラリ;test:指定testライブラリ

表名:*:すべての表;test:testテーブル

を指定

ユーザー名:必要な引用符

を任意に書く

IPアドレス:%:すべてのIPアドレスを表し、引用符を付けなければならない.

2.ビューを使用する.

create view ds_vuser as select id,tel,sex,portrait_url,name,status from ds_user

Tpはビューのピットを使用しており、通常ビューを使用する場合、v_という名前を付けます.userですが、tpはデータベースの接頭辞の問題で、設定するビュー名がテーブルの接頭辞と一致する必要があります.すなわちds_vuser. また、大文字と小文字の問題に注意してください.tpではMとDのパラメータの大文字と小文字に敏感です.テーブル接頭辞がds_に設定されている場合、D(「vuser」)対応するテーブル名はds_です.vuser;一方、D(‘vUser’)対応はds_であることを示すv_user.
ビューがセキュリティに与える影響は、上記の権限とともに使用することができ、テーブル構造を変更することなく、ユーザによるテーブルのデータの一部を制限する操作を完了することができる.すなわち、元のテーブル(table)のライセンスではなく、ユーザビュー(view)に付与ライセンスは、ライセンスに何の違いもない.
3.mysql注入防止.
Tpでは、where("id = $id")は安全ではないが、where(array('id'=>$id))はtpによってエスケープおよびフィルタリングされる.
オリジナルphpを使用する場合はmysqliとpdoのプリコンパイルとパラメータバインドを使用してsql注入を防止する.
4.パスワードsha 1を塩で暗号化する.
robots.txt
Robotsプロトコル(爬虫プロトコル、ロボットプロトコルなどとも呼ばれる)のフルネームは「ネットワーク爬虫排除基準」(Robots Exclusion Protocol)で、サイトはRobotsプロトコルを通じて検索エンジンにどのページがキャプチャできるのか、どのページがキャプチャできないのかを教えてくれます.
Robotsプロトコルは、Webサイトがセキュリティとプライバシーを考慮して、検索エンジンが機密情報をキャプチャすることを防止するために設定されています.
認証と権限制御
ロールベースのアクセス制御(Role-Based Access Control).
XSS攻撃を防ぐ

XSS攻撃は何ですか

クロススタンドスクリプト攻撃(Cross Site Scripting)
原理:悪意のある攻撃者はWebページに悪意のあるScriptコードを挿入し、ユーザーがそのページを閲覧すると、その中に埋め込まれたScriptコードが実行され、悪意のある攻撃ユーザーの目的を達成する.

よく見られる2つの防犯方式

htmlpurifier

をフィルタ

エスケープ

一般的なリッチテキストエディタは、安全を考慮するためにテキストを自動的に変換します.ueditorのように、tpのI()メソッドやcreate()メソッドもエスケープされ、リッチテキストコンパイラで追加するテキストが実際に2回エスケープされ、エコー時に正しく表示することができない.
CSRF攻撃の防止

CSRF攻撃は何ですか

CSRF(Cross-site request forgery)はサイト間で偽造を要求する.簡単に言えば、攻撃者はあなたの身分情報を利用して、あなたの名義で悪意のある要求を送信しました.
例:
1つの一般的な例は、銀行システムの振り替えがhttp要求によって振り替え操作を完了することである.悪意のあるユーザは、httpリクエスト(一般的にはリンクまたはフォームの自動コミットコード)を偽造することによって振り替えの目的を達成する.このことが可能になったのは、一般的に私たちの認証は、セッション情報クッキーがセッション情報を取得することによって判断され、ユーザーが銀行システムにログインし、セッションサイクルの有効期間内に、このブラウザがいくつかのファイルをロードしようとしたり、ユーザーにいくつかのリンクを注文したりした後、ユーザのブラウザはアイデンティティ情報を持って振り替え要求を完了した.
これはマルチウィンドウブラウザおよびクッキーの自動コミットメカニズムに関連する.
対策:

認証コード、すなわちコミットごとに認証コード検証が行われるが、これはユーザ体験

に影響を及ぼす.

は、要求ヘッダのreferヘッダを判断することによってユーザを選別するが、これは偽造することができ、場合によっては特殊な原因で、要求ヘッダのreferも空になるため、あまり信頼できない

である.

は、返されたデータに偽造防止フラグを付加する、これは主にサーバがhtmlデータに応答するときに、中にtokenトークンを付加し、ユーザーが要求を提出するときに、まずtokenトークンの正確性を検証し、正しくなったら操作を継続する.

私が今見ているすべてのフレームワークはthinkphpのフォームトークン、lavarelのcsrf_など、この方法を使用しています.token、workpressにも似たようなメカニズムがあります
フィールド検証
注意:前後で全部やる

フロントエンドが行う意味は、不要な要求を減らすことにある

.

バックエンドの意味は、セキュリティ検証

にある.
フロントエンドがやっていて、バックエンドがやっている必要はないと思う人もいますが、事実はそうではありません.原因は2つあります.プログラマーの究極の法則は、入力を信じてはいけない.フロントエンドエンジニアはユーザーの入力を信じられない.バックエンドエンジニアはフロントエンドの入力を信じられない.2.フロントエンドが完全に信頼できるとしても、すべてのリクエストがブラウザから来ているわけではないことを忘れないでください.
もう一つ注意すべきことは、極端な状況でもSERVERと_を信じないことです.ENVの値は、上記のように修正することができます.
php.iniのセキュリティ構成

本番環境クローズエラーメッセージ表示、同時オープンエラーログ記録

を覚えています.

は、いくつかの関数の使用を無効にすることができる.

また、phpを開くセキュリティモードは推奨されますが、phpの高バージョンでは廃棄されており、開くと多くのファイル操作や権限方法の問題が発生し、慎重に操作する必要があります.推奨しない
以上がWebプログラミングにおいてよく見られるセキュリティ問題である.
コメント
実際、以上の策略は、2つの部分の人を防ぎました.

の一部は「自分の人」、つまりプログラマーで、プログラマーにタイミングタスクをされてライブラリを削除されないでください.この部分は主にデータベース権限とビューの使用に現れるが、もちろんビューの使用はプログラマの操作権限を制御することに限らず、ビューのより主要な用途はデータベース操作を簡略化することであることが多い.

のもう一つの部分は、みんなが知っている様々なユーザーです.