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

はじめに

　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」を管理画面のパスに指定すると、エラーメッセージが表示されることが確認できます。

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

NAXSIのロゴ

はじめに

　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」

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

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

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

目次

TL;DR

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

LaravelのセッションCookieにSameSite属性を付与

はじめに

　Cookieの属性に「Domain」「path」「Max-Age」「Expires」「Secure」「HttpOnly」があるが、 『SameSite』というのも存在していることを知っていたか!?　私は最近まで知らなかった（恥ずかしい）。

　2016年から存在しており現在、主要なブラウザではサポートされているらしい。

--- 追記 2020/2/4 ---
　2020年2月リリース予定の Chrome 80 からはSameSite属性の値がないCookieはSameSite=Laxが付与されたものとして扱われるとのこと。

　SameSite属性を無効にしたい場合は明示的にSameSite=Noneを設定する必要があります。
Google Developers Japan: 新しい Cookie 設定 SameSite=None; Secure の準備を始めましょう

　LaravelのデフォルトではSameSite属性を付与しないようになっているため、SameSite属性を無効にする場合は「none」を明示的に指定する必要があります。
----- ここまで -----

そんな認知度が低そうな属性をLaravelで設定できるのかを確認してみる。

TL;DR

• Laravel 5.5.0 からサポート
• config/session.php を編集することでSameSite属性の値(Strict / Lax)の設定可能

【随時更新】Webセキュリティ診断ツールのまとめ

GUIアプリケーション型

　玄人向けのアプリケーションが多い印象です。

Burp Suite

公式	Burp Suite Scanner | PortSwigger https://portswigger.net/burp

• 診断を実施する上で便利な拡張プラグインが公開されている。独自に作成・公開することも可能です。 PortSwigger · GitHub

• GUIアプリケーション

• シナリオ型の設定可能

ZAP

公式	ZAP https://www.zaproxy.org/
GitHub	https://github.com/zaproxy/zaproxy

• GUIアプリケーション
• スパイダー型(簡易スキャン)
• 2023年8月にOWASPから離れた。そのため「OWASP ZAP」ではなくなった。

zap-cli

• Cookieの設定はコンテキストを読み込ませる必要があり難しそう

Dockerfile-zap-cli https://gist.github.com/Grunny/6ea8d48d711c6ad28064

Fiddler

　Windows上のデバッグでよく用いられるプロキシ。 今はMac OS向けもあります。

　アドオン（Watcher、X5S）を追加することによって診断を行うことが可能になります。

OWASP Fiddler Addons for Security Testing Project - OWASP

Vex

日本の会社が開発しているツールです。

公式	https://www.ubsecure.jp/vex

Watcher

公式	Watcher: Web security testing tool and passive vulnerability scanner - CodePlex Archive https://archive.codeplex.com/?p=websecuritytool

• パッシブスキャン

X5S

公式	x5s - test encodings and character transformations to find XSS hotspots - CodePlex Archive https://archive.codeplex.com/?p=xss

• アクティブスキャン

LDAPインジェクションをしたかった話【セキュリティ】

はじめに

今更ながらLDAPインジェクションがどのようなものなのかの検証をやってみました。

　LDAPインジェクションは脆弱性としてそこそこ有名であり、名前だけは目にすることがあるが、イマイチ実際に検証を行う気になれない脆弱性でもあると思う。特にLDAPの環境構築は手間になりそうだし。

　このままだとLDAPインジェクションを体験しないまま死んでしまってもおかしくないので、DockerでさくっとLDAPインジェクションの検証環境を構築し体験してみるとする。

検証環境

ホスト

• Docker 18.06.1

コンテナ

• OpenLDAP 2.4.44
  • osixia/openldap - Docker Hub
• PHP 7.0 （php-ldap）

【AWS】Security-JAWSの資料まとめ【第5~9回】

講演資料・スライド

第9回

◆ 【SecurityJAWS】Kibana Canvasで魅せる！AWS環境における脅威分析ユースケース

【SecurityJAWS】Kibana Canvasで魅せる！AWS環境における脅威分析ユースケース from Hibino Hisashi

www.slideshare.net

◆ Security JAWS 【第9回】勉強会 WAFシグネチャとログとAI

Security JAWS 【第9回】勉強会 WAFシグネチャとログとAI from Hiroshi Iwashita

www.slideshare.net

JAWS DAYSで話せなかった「Security x Serverless」の話
ー

攻撃者視点から考えるAWS EC2セキュリティインシデントとその対応
ー

自動車監視のためのクラウドソリューション（仮）
ー

第8回

◆ # Security JAWS Amazon GuardDuty 20180223

Security JAWS Amazon GuardDuty 20180223 from Hayato Kiriyama

www.slideshare.net

◆ 踏み台環境におけるAmazon Maice活用の提案 #secjaws #secjaws08 - Speaker Deck

speakerdeck.com

◆ VMware Cloud on AWS のご紹介 -セキュリティ風味-

VMware Cloud on AWS のご紹介 -セキュリティ風味- from Mitsutaka Ohisa

www.slideshare.net

事例に学ぶ、Splunk×AWSセキュリティモニタリングの具体策(仮)
ー

第7回

◆ AWS Security JAWS 経済的にハニーポットのログ分析をするためのベストプラクティス？

AWS Security JAWS 経済的にハニーポットのログ分析をするためのベストプラクティス？ from Masamitsu Maehara

www.slideshare.net

What you see is what you get 〜 インシデント対応するのに、まだログ分析で消耗してるの?
ー

Infocage SiteShell on AWS
ー

◆ Auth0でAWSの認証認可を強化

Auth0でAWSの認証認可を強化 from Hideya Furuta

www.slideshare.net

◆ 失敗事例で学ぶ負荷試験

失敗事例で学ぶ負荷試験 from 樽八 仲川

www.slideshare.net

AUTOMOXで俺たちのVulsが殺されるのか
ー

第6回

◆ ざっくりわかるAmazon Macie - Speaker Deck

speakerdeck.com

◆ Security JAWS #6 - Speaker Deck

speakerdeck.com

AWSで実践するリスト型アカウントハッキング対策（仮） -

◆ DevSecOps in Multi Account

DevSecOps in Multi Account from Tomoaki Sakatoku

www.slideshare.net

AWS環境におけるフォレンジック(仮)
ー

第5回

Deep SecurityとAWS WAF、SNS、Lambdaを使ってうまいこと自動防御する（仮）
ー

セキュリティのあるべき姿とSOCの重要性（仮）
ー

◆ 2017_0522 security-jaws_no5_Kawano_web_up

2017_0522 security-jaws_no5_Kawano_web_up from Shinichiro Kawano

www.slideshare.net

◆ AWS使って社内CTFやってみたよ - とある診断員の備忘録

tigerszk.hatenablog.com

参加レポート

第9回

Security-JAWS 第9回レポート #secjaws #secjaws09 ｜ Developers.IO
https://dev.classmethod.jp/cloud/aws/security-jaws-09-report/

第8回

Security-JAWS 第8回レポート #secjaws #secjaws08 ｜ Developers.IO
https://dev.classmethod.jp/cloud/aws/security-jaws-08-report/

第7回

ASCII.jp：ハニーポットから負荷試験の失敗事例まで、Security-JAWS勉強会 (1/3) http://ascii.jp/elem/000/001/594/1594177/

Security-JAWS第7回レポート #secjaws #secjaws07 ｜ Developers.IO https://dev.classmethod.jp/cloud/aws/security-jaws-07-report/

blog/20171113-Security-JAWS-7.md at master · wahho/blog https://github.com/wahho/blog/blob/master/20171113-Security-JAWS-7.md

第6回

ASCII.jp：たかがアカウント、されどアカウント、AWSでの運用ベストプラクティスは？
http://ascii.jp/elem/000/001/551/1551875/

ASCII.jp：オンプレとどこが違う？　実例に見るAWSでの不正アクセスの傾向と対策 http://ascii.jp/elem/000/001/549/1549718/

Security-JAWS第6回レポート #secjaws #secjaws06 ｜ Developers.IO
https://dev.classmethod.jp/study_meeting/security-jaws-06-report/

2017/08/24 Security-JAWS 【第6回】参加レポート - やーまんぶろぐ
http://yamano3201.hatenablog.jp/entry/2017/12/26/104439

第5回

Security-JAWS第5回レポート #secjaws #secjaws05 ｜ Developers.IO
https://dev.classmethod.jp/cloud/aws/security-jaws-05-report/

Security-JAWS#5レポート | cloudpack.media
https://cloudpack.media/31159

Security-JAWS#5レポート - Qiita
https://qiita.com/fnifni/items/73c9664aff0e639db62e

XSSI（Cross-Site Script Inclusion）攻撃とは【セキュリティ】

はじめに

　今回はWebセキュリティのお話です。

　とある機会にXSSI（Cross-Site Script Inclusion : クロスサイト・スクリプト・インクルージョン）攻撃というワードが話に出てきて、その攻撃が正直分からず困惑してしまったので、その攻撃について調べてみました。

　結論としては「Same-Origin Policy制限外のJSONPなどからは機密情報を外部ドメインから取得できる攻撃」です。

　本記事では、脆弱性あるサンプルアプリケーションを使い、実際に攻撃を行ってみて当脆弱性を確認していきます。

【THE 備忘録】Burp Suiteを使ってHTTPSサイトにアクセス

はじめに

　証明書のインポート毎に忘却しており、証明書探しの旅に出てしまっているので「THE 備忘録」

やること

• Burp SuiteのSSL証明書を Firefox にインポート

使ったブラウザ

• Firefox : 57.0.4

手順

1. 初期状態だと証明書エラー

SQLインジェクション体験ツール『SQLI-LABS』で遊ぶ

はじめに

　今回は「SQLI-LABS」を利用してさまざまなSQLi(SQL Injection)を学んでいきます。
SQLI-LABS はSQLi用やられWebアプリケーションで、SQLi攻撃を実際にやってみることでSQLiについて学ぶことができます。

　 SQLI-LABS は65種類(問題一覧からは75問あるように見えたが404だった...)のSQLiを学べるらしいので早速遊んでみました。

　動作DBはMySQLです。

• SQLI-LABS の開発リポジトリ github.com

環境構築

インストール

　インストールは非常に簡単で、リポジトリをWebサーバ上のドキュメントルート上に配置するだけ。

$ cd /var/www/html/
$ git clone https://github.com/Audi-1/sqli-labs.git
$ cd sqli-labs

Sambaの脆弱性〜CVE-2017-7494をやってみる〜

はじめに

　2017年5月24日に公開された、ファイル共有によく利用されるSambaの脆弱性「CVE-2017-7494」を実際に構築・PoCでの検証を行ってみます。

　脆弱性の概要・対策に関しては、下記の記事が参考になります。
Red Hat Customer Portal

oss.sios.com

【セキュリティ】jwt-goを使ってみる - その１

はじめに

　前回、RailsのJWTライブラリである"knock"を使って署名アルゴリズムにNoneを使えるのかを試してみた(使えなかった)ので、今回はGo言語のJWTライブラリである"jwt-go"を使って、署名アルゴリズムに「SHA256」と「none」を試した(使えた)ことを書いていきます。
motikan2010.hatenadiary.com

github.com