まったり技術ブログ

主にWebエンジニア向けのセキュリティ情報

OWASP Security Shepherdで入門するWebセキュリティ

f:id:motikan2010:20190824233013p:plain

  • はじめに
    • 公式サイト
  • DVWA(Damn Vulnerable Web Application)との違い
  • 環境構築
  • 試しに解いてみる
    • 問題 1 - 入力フォームが無い状態でのリクエスト改変
    • 問題 2 - JavaScript側のバリデーションの回避
  • AWS EC2で動作させる方法
  • まとめ

はじめに

 「OWASP Security Shepherd」はWebセキュリティを学ぶことができるアプリケーションです。
Webフレームワークを用いた場合にでも発生する可能性が高い脆弱性(リクエストパラメータの改ざん等)が取り上げられており、そのような脆弱性に対して実際に攻撃する経験をすることができます。
 Webフレームワークを用いての開発が主流となっている昨今でも非常に有意義な学習用ツールだと思っています。普段開発で用いらないローカルプロキシを使い始めるきっかけにもよいかと。

 使い方の流れとしては「ログイン → 問題を解く → スコアに反映」といった感じです。
構築も簡単であり、競技形式で学習ができるのが素晴らしい点だと思っています。
f:id:motikan2010:20190825000646p:plain

公式サイト

www.owasp.org

続きを読む

CVE-2019-11581 - 「Atlassian JIRA サーバーサイド・テンプレート・インジェクション」について調べてみた

f:id:motikan2010:20190728232522j:plain

 プロジェクト管理ツールとし有名なJira Serverの脆弱性が見つかりました。
脆弱性を含んでいるバージョンを利用しているかつ、特定の設定を有効にしている場合に、未ログインユーザでも「サーバーサイド・テンプレート・インジェクション(server-side template injection)」攻撃が可能ということで少し調べてみました。
 Pocも存在しており、実際にその検証している様子もありますので、Jiraサイトをパブリックに公開している運用している場合には、バージョンの確認・設定の確認を1度してみた方が良いでしょう。

  • 概要
    • 脆弱性についてより詳しく
  • 検証情報(キャプチャ画像有り)
  • PoC(検証コード)
  • 検証
    • 検証パッケージ(Jira Server 7.13.4)
    • Jira Server インストール手順(AWS)
  • 攻撃可能な設定
  • 対応
  • まとめ
続きを読む

最悪の管理画面URLランキング

f:id:motikan2010:20190617024001p:plain
  • はじめに
  • 確認したツール
  • 最悪な管理画面URLランキング
    • 1位 - 全てのツールで検索対象
    • 2位 - 5つのツールで検索対象
    • 3位 - 4つのツールで検索対象
    • 4位以下 - 1~3つのツールで検索対象
  • まとめ

はじめに

 Webサイトの管理画面が推測されることにより、サイトの改ざん等の被害が増えてきているようで、先月(5/9)にEC-CUBEでは下記のような注意喚起がありました。
 以下、注意喚起の一部抜粋。

  1. 管理画⾯の URL が /admin/ など推測されやすい URL になっていないか 管理画⾯の URL を変更せず /admin/ のままで運⽤していた場合、攻撃者が管理画⾯にア クセスしやすい状況になっておりますので、 早急に変更をお願いします。

【重要】サイト改ざんによるクレジットカード流出被害が増加しています。

 ここで述べられている推測されやすいURLの代表例として、ツールによって発見されるURLであることがあります。
 なので今回は各ツールがどのようなURL(管理画面へのパス)を検索しているのかを調べてみました。

確認したツール

 今回確認したツールは以下の6つです。

  • OWASP ZAP
  • Arachni
  • Nikto
  • skipfish
  • Wfuzz
  • WAScan

最悪な管理画面URLランキング

1位 - 全てのツールで検索対象

admin
administrator

 「admin」「administrator」パスはツール全てで検索されていました。

 EC-CUBEでは、インストール時に管理画面のパス名を指定することができるようになっていますが、「admin」というパス名は指定できないようになっており「admin」がパスとして利用される危険性の考慮がされていることが分かります。 「admin」を管理画面のパスに指定すると、下記のエラーメッセージが表示されます。 f:id:motikan2010:20190616204123p:plain:w500

続きを読む

WAF for Nginx「NAXSI」を動的モジュールとして読み込む

NAXSI-Logo
NAXSIのロゴ

  • はじめに
  • 環境
  • 導入作業
    • Nginxインストール
      • リポジトリ追加
      • インストール
    • NAXSIモジュールをビルド
    • NAXSIモジュールのロード
    • ログファイルの作成
    • Nginx設定ファイル修正
    • Nginxの起動
    • 動作確認
      • 不正なリクエストを送信
      • 検出ログ
    • ブロックはしたくないけど、検出はしたい
    •  参考

はじめに

 NAXSI(Nginx Anti XSS & SQL Injection)はOSSのWAFであり、スター数が3,000を超える人気を誇っており、利用してみたくなったので、インストールしてみました。
 ちなみにOSSのWAFとして有名なModSecurityのスター数は約2,800です。(NAXSIすごい...)

github.com

環境

  • CentOS 7.4
  • Nginx 1.16.0
  • NAXSI
続きを読む

CookieのSameSite属性で「防げるCSRF」と「防げないCSRF」

f:id:motikan2010:20190202110454p:plain

 CookieのSameSite属性はCSRF対策のために提案されたもので、その属性をCookieに付与するだけでほとんどのサイトの場合はCSRF対策が可能になります。
しかし、SameSite属性の付与が今までのCSRF対策の代わりになり、今まで行ってきたCSRF対策をしなくてよくなるというわけではありません。

 CSRF対策の為に提案された属性ですが、サイトの特性によってはCSRFを防ぐことができない場合があります。
今回は、その「防げないCSRF」とはどういったものであるのか、一例をあげます。

 そして実際にSameSite属性付与が付与される脆弱なサンプルサイトを使って説明していきます。

目次

  • 目次
  • TL;DR
  • サンプルアプリケーションを用いての検証
    • サンプルサイトの機能
    • CSRFの確認
      • CSRFトークンを用いている場合
      • SameSite属性を用いている場合
  • まとめ

TL;DR

  • 「防げるCSRF」とはセッションが存在しているサイト
  • 「防げないCSRF」とはセッションを利用していないサイト
  • SameSite属性は充分にCSRF対策の効果がある
続きを読む