どーもー、某IT企業で働いているエンジニアです。
先日、当社では年に1回おこなわれるセキュリティ診断がありました。
私が担当しているサービスも上記の対象だったわけですが、その中で、当社のセキュリティ診断が「OWASP-Top10」を元にしている事が分かりました。
「OWASP」という名前自体、僕自身初めて聞いたのですが、調べてみると、
そして、OWASP-Top10は、世界基準のWebアプリケーション-セキュリティリスクTOP10。
・OWASP Top10(2017)：最も重大なウェブアプリケーションリスクトップ10
まあセキュリティ対策のデファクト・スタンダードと言っていいでしょう。
（最新版は、2017年版で。その前は2013年とのこと。毎年更新されてるわけでは無いらしい）
というわけで、エンジニアとして働く以上セキュリティ対策は避けては通れないので、僕も上記の資料を一通り見てみました。
そして今回は、上記を見た上で、僕なりに分かりにくかった部分や追加で情報収集した部分含め、分かりやすいように当記事にOWASP-Top10の項目をまとめてみました。
ぜひ、僕と同じエンジニアの方や、今後セキュリティエンジニアに転職したいといった方に、見てほしいと思います。
以下、目次。
- SQLインジェクション
- 認証
- データの扱い
- XML外部エンティティ参照 (XXE)
- アクセス制御
- 不適切なシステム・セキュリティ設定
- クロスサイトスクリプティング (XSS)
- デシリアライゼーション（オブジェクトインジェクション）
- 脆弱性のあるライブラリ・コンポーネント
- ロギングとモニタリング
１、SQLインジェクション ～OWASP-TOP10
こちら、ハッキング手法で最も一般的なものと言っていいでしょう。
DB関連の攻撃ですね。
以下、分かりやすいように攻撃の例を挙げていきたいと思います。
例えば、以下のような会員データを表示させる画面があるとします。
こちら、入力フォームに会員IDを入力して、該当の会員情報を表示させる画面になります。
表示させる時のSQLを以下としましょう。
通常であれば、会員IDに「1」とか「1234」といった値を入力して、該当の会員情報を表示させるわけですが、
ここに、「’ or ‘1’=’1」を入力すると、条件の「or 1=1」で、全会員データの情報を表示させることになってしまうわけです。
対策としては、ちゃんと入力値をチェックし、サニタイズ、フィルタリングすること。
入力値を、SQLとして認識させるのでは無く、単なる文字列として認識させることが重要なわけです。
一般的な実装対策としては、予め select、update、insertと、データ操作用の共通処理を用意しておいて、データ操作する場合は常にそれを利用するというのが、一般的でしょう。（当然、その処理の中でSQLインジェクションを対策しておきます）
以上です。
２、認証 ～セキュリティリスクTOP10
こちらは、アプリーケーションの認証設定が甘い場合のセキュリティリスクになります。
例として、管理者ページへのログインを試みるハッキング手法の一つに「アカウントリスト攻撃（総当たり攻撃）」というものがありますが、
これは、膨大な量のユーザ名とパスワードの組み合わせリストを用意しておき、これらの値をもとに自動で順々にログインを試みるといった手法になります。
これによって、ユーザ名とパスワードの値が「よくありがちな値」だったりして認証設定が甘いと、攻撃者にログインされてしまう恐れがあるわけです。
なので対策としては、ユーザ名とパスワードを複雑な値にして、かつそれだけじゃなく、ログインページへのIP制限、ログイン失敗の回数制限、あとは、ワンタイムパスワードを利用する多要素認証を実装することが有効でしょう。
あとは、セッションの設定に不備があったりしても、上記とは別のルートで管理者ページに侵入されたりします。
セッションタイムアウトが未設定だったり、ブラウザを閉じてもセッション情報が残り続けるような設定になっている場合は、非常に危険です。（ハッキング者が、同じPCでブラウザを起動することによって、そのまま管理者ページにアクセスする事が可能になります）
３、データの扱い ～OWASP-TOP10
ここでいう、「データの扱い」というのは重要なデータをちゃんと暗号化して扱っているか・・・
当然、パスワード情報なんかは暗号化していないといけません。でないと、仮にSQLインジェクションなどで情報を取得されたときに、平文のままだと被害がさらに広がる可能性が高いですからね。
また、通信もHTTPじゃなくてHTTPSにすること。じゃないと、セッション情報を傍受されてしまった場合、その情報で管理者ページへアクセスされてしまう恐れがあります。
４、XML外部エンティティ参照 (XXE) ～セキュリティリスクTOP10
「XXE」とは、WebアプリケーションがXMLファイルを読み取る機能を実装している場合、それに対して悪意のあるXMLファイルをアップロードすることを指します。
例えば、以下のXMLなんかは、攻撃者がサーバーからパスワードの情報を盗み出そうと試みている内容になります。
もし仮に、アップロードされたXMLファイルの内容を表示させる。といった処理の場合、以下によってパスワードが公開されてしまいます
<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>
５、アクセス制御 ～OWASP-TOP10
こちらは、アプリケーションのアクセス制御に不備があった場合に、そこを突いてこられるとヤバイセキュリティ的な問題のことです。
例えば、外部のユーザーが管理者ページにアクセスすることができる脆弱性だったり、他人の情報を表示させたり、削除したりできる脆弱性がここでは該当します。
通常、管理者ページはセッション管理がされていると思いますが、セッション情報を保持していないにも関わらず、管理者ページにアクセスできたり・・・とか。
このように、セッション管理に不備があると、他人の管理者ページにアクセスできたり、情報を表示させたり。といった事が可能になってしまいます。
６、不適切なシステム・セキュリティ設定 ～セキュリティリスクTOP10
ここの項目は定義が広いので、色々と当てはまりますが、例えば
・ファイルのパーミッション設定に不備がある。
・アパッチのディレクトリ-リスティングが有効になっていて、サーバー上のディレクトリ構成が見れてしまう。。
等々。
７、クロスサイトスクリプティング (XSS) ～OWASP-TOP10
クロスサイトスクリプティングは、Webページ上の入力フォーム等に、javascriptを埋め込むことが許容されている脆弱性になります。
それによって、悪意のあるJSが実行されてしまう恐れがあります。
例えば、以下のようなIDを入力する入力フォームがページにあった場合、
通常であれば、上記のように「aaa」とか「123」とかを入力すると思うのですが、以下のような悪意のあるJSが埋め込まれると・・・
攻撃者のウェブサイトに対して、クッキー情報が送信されてしまい、セッションが乗っ取られてしまったりします。
このように、セキュリティ的にXSSの脆弱性があると、セッションの奪取によりアカウントが乗っ取られたり、Webページ（HTML）のDOMが変更されたり、ウィルスのダウンロードURLが設定されたりします。
XSSの対策としては入力フォームの値をちゃんとチェックし、サニタイズ、フィルタリングすることです。（JSとして認識させるのではなく、単なる文字列として認識させるようにします）
８、デシリアライゼーション（オブジェクトインジェクション） ～セキュリティリスクTOP10
まず、デシリアライゼーションとは・・・アプリケーションでデータを保存したり、ユーザーにデータを送信する際、データ（オブジェクト）を保存や送信が可能なデータ形式に変換する必要があります。これを「シリアライゼーション」と言います。
そして、保存された（シリアライゼーションされた）データを表示したり、送られてきたデータを受信する際に、再度データをユーザー（人間）が確認できる形式に変換することを、「デシリアライゼーション」と言います。
で、、
本来であれば、シリアライゼーションされたデータが、デシリアライゼーションされる事になるのですが、ハッキングによって、シリアライゼーションされたデータ（オブジェクト）が、悪意のあるデータに入れ替えられ、
それを、気づかぬままデシリアライゼーションしてデータを読み取ってしまったために、被害を受けてしまう。といった事があります。
例えば、以下のようなサーバーサイドの処理があるとしましょう。
print_r($foo);
$result = $foo->init();
上記は、クッキーに含まれているオブジェクトを読み込んで、そのオブジェクトを表示して、そのオブジェクトの処理（init）を実行しているのですが、
仮にこのクッキーに含まれているオブジェクトを悪意のあるデータに入れ替えられたとしたら、悪意のある処理を実行させることができるわけです。
このように、オブジェクトのデータを差し替えるハッキング手法を、オブジェクトインジェクションと呼びます。
（上記のように、hidden値やクッキー情報の差し替えが一般的です）
対応策としては、シリアライズされたオブジェクトを送信してくる送信元をチェックする必要があります（デジタル署名などの整合性チェックを実装する）
参考元：安全でないデシリアライゼーション(Insecure Deserialization)入門
９、脆弱性のあるライブラリ・コンポーネント ～OWASP-TOP10
これは、アプリケーションを実装するうえで、外部のライブラリ（DLL等）や、フレームワークを利用していたり、あとはアパッチ等のミドルウェアも影響してきます。
対策としては、セキュリティ的に脆弱性のあるライブラリ（DLL等）は利用しない事。
そして、利用しているライブラリやミドルウェアは、なるべく最新のバージョンにアップデートしておくことです。（古いバージョンだと既知の脆弱性があったりするので）
１０、ロギングとモニタリング ～セキュリティリスクTOP10
こちらは、ちゃんとアプリケーションの各操作履歴や状態をログに残し、モニタリングしておきましょう。って話です。
例えば、ログインですが、誰がいつログインしているのか。これをログに残しておくことで、短期間で多々ログインを試みてる怪しいアカウントがある。って事が判明しますし、
1分間に10回以上のログイン失敗で、管理者にメールを送信する。。。といったモニタリング体制をとっておけば、すぐに不正行為に対して気づくことができます。
もちろん、ログインに関わらず、重要な処理のログだったり、警告やエラーに関してもきちんとログを取っておくことが重要です。
というわけで、以上「OWASP-Top10」の内容でした。
エンジニアとして働いていきたいのであれば、知っていて当然の内容ばかりなので、ぜひ理解しておいてください。
もちろん、今後エンジニアとして働きたい。っていう転職を検討している方も。
では。