脆弱性について

主にウェブアプリケーション、サイトについて


Index

  • A 概要
  • B 脆弱性を自分で体験する診断ツール
  • C 一般的な区分
  • D それぞれの詳細、対策
  • E 補足,未整理

A 概要


B 脆弱性を自分で体験する診断ツール

脆弱性診断ツール OWASP ZAP vs 脆弱性だらけのWebアプリケーションEasyBuggy

Owasp Top 10なども参考に

セキュリティ・脆弱性診断無料ツール・有料サービスの比較と選び方


C 区分

1 認証

  • [ ] 1-1 パスワードポリシー
  • [ ] 1-2 不適切な認証
  • [ ] 1-3 脆弱なパスワードリマインダ

2 承認

  • [ ] 2-1 セッションの推測
  • [ ] 2-2 不適切な承認
  • [ ] 2-3 セッションの固定
  • [ ] 2-4 クロスサイトリクエストフォージェリ

  • [ ] 2-5 補足:Cookieで「secure 属性」を指定 保険的な対策

  • [ ] 2-6 セッションハイジャック

3 クライアントがわでの攻撃

  • [ ] 3-1 クロスサイトスクリプティング
  • [ ] 3-2 コンテンツの詐称

4 コマンドの実行

  • [ ] 4-1 バッファオーバーフロー
  • [ ] 4-2 書式文字列攻撃
  • [ ] 4-3 LDAP インジェクション
  • [ ] 4-4 OS コマンドインジェクション
  • [ ] 4-5 SQL インジェクション
  • [ ] 4-6 SSI インジェクション
  • [ ] 4-7 XPath インジェクション

5 情報公開

  • [ ] 5-1 ディレクトリインデクシング
  • [ ] 5-2 ソース記載による情報漏えい
  • [ ] 5-3 推測可能なリソース位置

  • [ ] 5-4 ディレクトリトラバーサル

6 ロジックを狙った攻撃

  • [ ] 6-1 機能の悪用
  • [ ] 6-2 パス・トラバーサル
  • [ ] 6-3 リダイレクタ
  • [ ] 6-4 不適切なプロセスの検証

7 その他、概念的にまとめた物

  • [ ] 7-1 ヌルバイト攻撃
  • [ ] 7-2 メールヘッダ・インジェクション、メール第三者中継
  • [ ] 7-3 HTTPヘッダインジェクション、HTTPレスポンス分割攻撃
  • [ ] 7-4 スクリプトインサーション

D それぞれの詳細、対策

1 認証

1-1 パスワードポリシー

簡易なパスワードにしないなどのポリシー

1-2 不適切な認証

1-3 脆弱なパスワードリマインダ

パスワードを忘れた場合に、QAなどでログインできてしまうやつ

2 承認

  • 対策コード
// HTTPS限定の物を含む設定
session_name("randamunasuujinadonado"); // A) sessionidを任意の物に変更
ini_set('session.cookie_secure', 1); // B) secureな状態でのみcookieの通信を行う。

//有効期限を設定、例えば1日
$exipires__dd = 60*60*24 ; 
ini_set('session.gc_maxlifetime', $exipires__dd);
ini_set('session.cookie_lifetime', $exipires__dd);
session_start();
  • 補足: session.cookie_secureを設定するとhttp環境ではアクセス毎にクッキーが更新されてしまう。
    https下で使うのが望ましい。

  • 補足: session,cookie それぞれの有効期限の話
    https://teratail.com/questions/33522

2-1 セッションの推測

セッションIDの推測

  • PHPSSEIDのように推測しやすいやつ
  • 連番によるセッションID
  • 桁数の少ないセッションID
  • ユーザ情報を単純にハッシュしたセッションID

2-2 不適切な承認

不適切な承認

cookieの書き換えでログイン状態になるとか・・・

2-3 セッションの固定

セッションの中身までが固定で決まってる・・・・

2-4 クロスサイトリクエストフォージェリ

CSRF対策

csrf対策用のhiddenキーを仕込むのも一般的

2-5 補足:Cookieで「secure 属性」を指定 保険的な対策

2-6 セッションハイジャック

3-1 対応


# 対策系 # 全てsページの場合での注意は必要 Header always append X-Frame-Options SAMEORIGIN Header always set X-Content-Type-Options "nosniff" Header always set X-XSS-Protection "1; mode=block" Header set Strict-Transport-Security "max-age=315360000; includeSubDomains; preload"

3 クライアントがわでの攻撃

  • HTTP リクエストの作成などに / chrom extension REST Client
    https://qiita.com/KAZ0225/items/354b7726e650e9bda45d

上記でTRACEを送る方法で405で返ってくれば対策はされてると考えて良い。

3-1 クロスサイトスクリプティング

クロスサイトスクリプティング対策 ホンキのキホン

クロスサイトスクリプティング対策としてやるべき5つのこと

テンプレートエンジンを使う事により、対策となる物も

3-2 コンテンツの詐称

4 コマンドの実行

4-1 バッファオーバーフロー

4-2 書式文字列攻撃

4-3 LDAP インジェクション

4-4 OS コマンドインジェクション

http://senmon.cfc.ac.jp/studentreport/report2/OS.html

4-6 SSI インジェクション

http://securitychecklist.net/security/cyber-attack/SSL-injection.html

4-7 XPath インジェクション

ユーザの入力に基づき、XMLドキュメントに対してクエリーを発行するようなWebシステムで発生
http://www.soi.wide.ad.jp/class/20040011/slides/18/33.html

5 情報公開

5-1 ディレクトリインデクシング

ディレクトリリスティングの危険性と対策方法

ディレクトリリスティングの危険性と対策方法

5-2 ソース記載による情報漏えい

5-3 推測可能なリソース位置

http://www.soi.wide.ad.jp/class/20040011/slides/18/38.html

6-1 機能の悪用

6-2 パストラバーサルについて

ディレクトリ・トラバーサルと対策

6-3 リダイレクタ

オープンリダイレクタ脆弱性に気をつける

6-4 不適切なプロセスの検証

7 その他、概念的にまとめた物

7-1 ヌルバイト攻撃

7-2 メールヘッダ・インジェクション、メール第三者中継

7-3 HTTPヘッダインジェクション、HTTPレスポンス分割攻撃

7-4 スクリプトインサーション


E 補足,未整理

  • telnet

Windows telnet コマンドで入力文字を表示する方法

HTTP/TELNETを利用してHTTPレスポンスヘッダを確認する

※ ただしtelnetはhttpsなどに非対応

telnetはHTTPSを喋れないので、openssl s_clientを使えばいい

どんな場面でhtaccessを使うのか?

apcheのhttpd.confで、出来る物に関してはそちらで対応した方が良い。
運用上のリダイレクトや共用サーバーでconfファイルがいじれない場合などに利用する。

  • リダイレクト処理
  • アクセス制限
  • URLの統一

などに使用する


前提条件

httpd.confファイルにて,AllowOverrideが有効になっている必要がある

<Directory />
~中略~
AllowOverride None
~中略~
</Directory>

<Directory "対象となるディレクトリ 例) /var/home/www">
~中略~
AllowOverride All
~中略~
</Directory>


リダイレクト処理について

シンボリックリンクを許可し、RewriteEngineをOnにする

.htaccessのでRewriteEngineをOnにするにはOptions FollowSymLinksを設定しなければならないとApacheの公式サイトにあります。

Options +SymLinksIfOwnerMatch

リダイレクト処理について


アクセスの制限と許可

htaccessへの直接のアクセスを制限

直接ブラウザなどから.htaccessにアクセスできないように制限する。

<Files ~ "^\.ht">
deny from all
</Files>

BASIC認証

別途 .htpasswdファイルが必要

ベーシック認証の暗号化形式にも注意
Password Formats

AuthTYpe Basic
AuthName "Input your ID and Password"
AuthUserFile /home/current/.htpasswd
AuthGroupFile /dev/null
Require valid-user

  • AuthTYpe Basic

現行ダイジェスト認証に対応しているブラウザも多いため、そちらを利用するのも良い

AuthTYpe Digest
※ Digest認証だと、ユーザーIDとパスワードがハッシュ関数を用いて暗号化され解析されにくくなります。
  • AuthGroupFile /dev/null
    グループ指定が無いという意味、グループを使用する場合は
    .htgroupファイルが必要

    ※グループやRequire の記述で.htpasswdファイルは一つで
    各ディレクトリ毎に.htaccessを用意して権限を分けやすくするというメリットはある。

参照

IP制限

BASIC認証、もしくはIP制限

Satisfy Anyがポイント

Basic認証の記述 + Satisfy Any + IP制限、許可 の順番で記述する。

AuthType Basic
AuthName "Input your ID and Password"
AuthUserFile /home/current/.htpasswd
AuthGroupFile /dev/null
Require valid-user

Satisfy Any

order allow,deny
allow from 100.100.100.100

細かくはこちらを参照

その他、細かなファイルや拡張子単位での制限


URLの統一

httpsに統一する

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

wwwありなしの統一

※ 前提条件として www.はサブドメイン


番外 FTPのIPアクセス制限(.ftpaccess)

  • [FTP接続制御!IPアドレスによるアクセス制限設定をする方法](https://www.nkshopping.biz/index.php?
    FTP%E6%8E%A5%E7%B6%9A%E5%88%B6%E5%BE%A1%EF%BC%81IP%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E3%81%AB%E3%82%88%E3%82%8B%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E5%88%B6%E9%99%90%E8%A8%AD%E5%AE%9A%E3%82%92%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95)