Webセキュリティの実践のための攻防戦演習について
•Transferir como PPTX, PDF•
0 gostou•665 visualizações
PHPカンファレンス福岡2017
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Webセキュリティの実践のための攻防戦演習について
Semelhante a Webセキュリティの実践のための攻防戦演習について (20)
Webセキュリティの実践のための攻防戦演習について
- 2. 攻防戦演習 各チームに与えられたサーバ間で 脆弱性を突く攻撃と それから守る防御を競う競技です。 早く脆弱性を見つけ攻撃するだけでなく、 見つけた脆弱性から自分たちを守る 必要があります。 競技中にやること 他チームのサーバーから情報を抜き出すこと 他チームのサーバーの運営を妨害する
- 5. 動作確認の仕組み スコア サーバー チームA 動作を確認するス クリプトを走らせ て結果を取得 { "defense_type_id": 3, "result": 1, "team_Id": 2, "token": ***************** } 結果を スコアサーバーに 送信
- 7. 得点方式 攻撃ポイント 他チームのサーバからフラグを窃取し、スコアボードにサブミッ トすると点数が得られます。 各フラグには有効期限があり、有効期限経過後はサブミットして も得点できません。 有効なフラグがサブミットされた場合、その時点の窃取された チームの総得点の3%が、サブミットしたチームに移動します。 スコアサーバーへのサブミットは競技時間内に完了させる必要が あります。
- 8. 得点方式 防御ポイント 運営は、サービスごとに定期的に稼働状態をチェックします。 稼働状態のチェック方法は非公開です。 稼働が確認できた場合は、100点の点数が得られます。 同じサービスについて連続して稼働が確認できた場合は、その回数 に応じて1点ずつ加算します。 (2連続の場合は1点、3連続の場合は2点、4連続の場合は3点) 稼働が確認でなかった場合は、その時点の総得点の3%を減算します。
- 9. 攻撃ポイント フラグは基本的に、スコアサーバーが動作確認を行う際のスクリプトに 仕込んでおり、それにより登録される。 奪取したチームの総得点の3%が入る仕様だが、 フラグには登録してから1時間という時間制限をかけているため、 そのため、スコアサーバーに登録するタイミングも重要。 97 50 194 50 3 3 6 6 チームA チームB チームA チームB チームBがフラグ を登録した時に、 チームAの特典が 100点であれば3点 奪取される チームBがフラグ を登録した時に、 チームAの特典が 200点であれば6点 奪取される
- 10. 防御ポイント 運営は、サービスごとに定期的に稼働状態をチェックします。 稼働が確認できた場合は、100点の点数が得られます。 同じサービスについて連続して稼働が確認できた場合は、その回数に応じて1点ずつ 加算します。(2連続の場合は1点、3連続の場合は2点、4連続の場合は3点) 稼働が確認でなかった場合は、その時点の総得点の3%を減算します。 0 200 400 600 800 1000 1200 1400 10:00 10:05 10:10 10:15 10:20 10:25 10:30 10:35 10:40 10:45 10:50 10:55 11:00 チームA チームB チームC 最初の稼働はでき たがその後落ちた 場合。 ずっと稼働し続 けた場合。 途中で落ちたり 復帰したりを繰 り返した場合。
- 12. 問題例 PHPで作られた誰でも投稿できるブログ 管理画面があり、管理画面のパスワードが平文で公開ディレクトリに 置かれている。 またいろいろなところに XSSやSQLインジェクションの脆弱性 が存在する。
- 13. 問題例 PHPで作られたお問い合わせと掲示板がある会社のページ 裏にシステム管理用のページが存在し何かに使われている。 昔ながらの作りをしており、様々な脆弱性が存在している。
- 14. SLA1 チェック サーバー date Sat Jun 10 00:13:42 JST 2017 OSコマンドを実行 できるフォーム SLAのスクリプトがOSコマンドを投げてくるため このフォームにOSコマンドインジェクションの脆弱性あるじゃん！ ふさいでしまおう！とやってしまうとSLAが落ちる。
- 15. SLA2 チェック サーバー service httpd status OSコマンドを実行 できるフォーム SLA1の修正でdateコマンドだけ許可した場合、 こっちでは、service httpd statusを送ってくるので こっちのSLAが落ちる。
- 18. おわりに 先ほど紹介した問題は、福岡、北海道の計2回程度開催を行ったが、脆弱性の 修正といった点では、各チームとも修正はできているが、サービスの継続とい う観点が抜けていたために修正時に防御ポイントが落ちることが多かった。 チェックサーバーから送信されるSLAの確認 ログ、POSTの値、パケットなどから 開催した際はバーチャルマシンを用いて行っていたため、 SSHでサーバーに接続してから作業する必要があり、 ある程度、Linuxの操作になれている必要があるため、 この段階で難しいと感じる参加者もいたようだ。