WPScanとバージョン検出の網羅性

よく「Wordpress セキュリティ対策」でググると攻撃者に余計な情報を与えないという意味で「バージョン情報を非表示にする」と書いてある記事がちらほらあるのですが、Wordpressで構築されたサイト内にバージョン情報を消しきれてないケースがあることに気づきました。 よくある記事で紹介されているのは下記の2パターンがメイン。 各ページのMETAタグにバージョン情報が表示されているケース jsやcssなどのassetsファイルにバージョン情報がパラメータとして付与されているケース atomやrdfなどのfeedに記載されていることもあったり、古いWordpressだとreadme.htmlに大きく記載されていることもある。 なので、バージョン情報が記載されている箇所をある程度網羅する必要がある。 そこで利用するのがWPScan。 WPScanは、ブラックボックス型のWordpressの脆弱性スキャナで、自身で構築したWordpressの検査に時々利用している。 gemでインストールできるのだが、Docker Imageもあるので、普段はこちらを利用しています。 https://hub.docker.com/r/wpscanteam/wpscan/ 通常の利用方法でもバージョン情報を検出は可能なのだが、検出できた時点で探索をやめてしまうので、網羅的に探すことができない。 $ docker run -it --rm wpscanteam/wpscan --url https://target.tld/ と困っていたところ、 --wp-version-all というオプションがあることを教えてもらった。これでバージョン情報が表示されている場所をある程度網羅ができそう。 $ docker run -it --rm wpscanteam/wpscan --url https://target.tld/ --wp-version-all マニュアルに載っていないなと思ったら --hh オプションのマニュアルにちゃんと書いてあった^^; ここまでやっておいてなんだけど、バージョンを非表示にすることよりもちゃんと最新版にアップデートしていくほうに時間を使いたい。 »

[Mac]SafariのXSSAuditorを無効化する

SafariでXSSのテストをしたい時に、何度かブラウザの機能で止められることがあった。 Chromeは[Mac]GoogleChromeのXSSAuditorを無効化する で書いたように 起動オプションで無効化できるが、Safariでのやり方がわからなくてググってた。 SafariではTerminalを開いて下記のコマンドでXSSAuditorを無効化できる。コマンドを実行後、Safariを再起動する。 $ defaults write com.apple.Safari "com.apple.Safari.ContentPageGroupIdentifier.WebKit2XSSAuditorEnabled" -bool FALSE 有効化したい場合は、コマンド末尾の-boolオプションをTRUEに変更するだけ。 参考 XSSAuditor - discussions.apple.com »

AlexaのプロアクティブイベントAPIを使ってみる

Alexaを買ったのはちょうど一年前くらい。 Alexaにいろいろ通知ができないかといろいろ模索してた時期があって、 そのときは通知用のAPIがβ版になっていてAmazonに申請しないと使えなかったのですが、最近調べたらプロアクティブイベントAPIなるものが出てるらしく遊んでみた。 https://twitter.com/328__/status/1112307063672061953 プロアクティブイベントAPI - amazon alexa プロアクティブイベントAPIとは? 一言で言うとサーバ側からAlexaにPUSH通知を行うことができるAPIです。 Alexaは基本的にユーザがEchoに呼びかけてサーバから結果を取得するいわば「フェッチ型」です。 このプロアクティブイベントAPIを利用すると、ユーザがEchoに呼びかけなくてもサーバ側から通知を送ってくれる「プッシュ型」の処理が作れるわけです。 とはいっても、このAPIだけでは好きな言葉をベラベラ喋らせれることはできなくて、ある定型文に沿って喋らせることができるだけです。 それと、「Alexa, 通知は何?」って聞かないと結果は返してくれません。 ※ 聞かなくても勝手に返してくれる方法があれば誰か教えてください 使ってみる https://github.com/328/alexa-proactive-api-test 1. ツールのインストール https://serverless.com https://developer.amazon.com/ja/docs/smapi/ask-cli-command-reference.html 2. AlexaDeveloperコンソールからスキルを作成 LambdaのトリガーにスキルIDが必要になるのでこちらを控えておく。 スキルIDはAlexaスキルのアプリ名の下に「スキルIDの表示」というボタンがあるのでそこを押下すると表示される。 3. ServerlessFrameworkで空のLambdaを作成 https://github.com/328/alexa-proactive-api-test/blob/master/lambda/subscribe-event-lambda/serverless.yml#L16 ↑の __SKILLID__ 部分を手順2で控えたスキルIDに差し替えて # sls deploy でデプロイを実行する。LambdaのARNを控える。 4. askコマンドでプロジェクトをデプロイを実行 uri内の __LAMBDA_ENDPOINT__ を手順3で控えたARNに変更する。 https://github.com/328/alexa-proactive-api-test/blob/master/skill.json configのskillIdを記載 https://github.com/328/alexa-proactive-api-test/blob/master/.ask/config#L4 ask deploy でデプロイを実行します。 5. Alexaコンソールから通知の許可を実行 https://alexa.amazon.co.jp にアクセスします。 「有効なスキル→作成したアプリをクリック→設定→アクセス権を管理→Alexaの通知をON→アクセス権を保存」で通知を許可します。 これやってなくてハマってしまった…^^; 6. クライアントIDとクライアントシークレットを控える alexa developer consoleから「アプリ→アクセス権限→Alexaスキルメッセージング」からクライアントIDとクライアントシークレットの2つを控える »

307 Temporary Redirect

HTTPのステータスコード3xxといえば、Redirectionなのですが、 300,301,302,303,304,305,306,307といろいろあります。 302,303,304はよく見かけるのですが 最近、HTTPのステータスコードを見かけて気になったので 307を調べたのでそのときのメモ。 w3c.orgのサイトでは、307はTemporary Redirectionとなっている。 HTTP/1.1 Status Code Definitions - w3.org これなにかというと、サーバからリダイレクト要求が行われた時に、メソッドと本文が変更されないことが保証されるものです。 たとえばHTTPサーバAに何かしらのデータをPOSTしたときに, HTTPサーバBへのリダイレクト要求(307)を返したとします。それを受け取ったHTTPクライアントは、HTTPサーバAにPOSTしたデータと同じものをHTTPサーバBへPOSTします。 よくあるサイトの1つとして、更新処理をするとトップ画面に遷移する的なものがあり、302が多いのですが、302はリダイレクト先にアクセスする際のメソッドを変更してはならない(GETだったらGET, POSTだったらPOSTでリダイレクト先にリクエストする)ものなのですが、その実装を守っていないクライアントがあって303,307が追加されたようです。 HTTPステータスコード – 302 Foundと303 See Otherと307 Temporary Redirectの違いについて / cyano 307の挙動を確認 307の挙動を見たいので下記のコードをPHPで作成しました。 このコードを配置したサーバに対してPOSTメソッドでアクセスし307が返却された場合に、POSTメソッドと本文を保持したままリダイレクト先にPOSTメソッドでアクセスします。 リダイレクト元 リダイレクト先 303の挙動を確認 ちなみにPOSTメソッドでアクセスして303が返却されると、リダイレクト先はGETメソッドでアクセスします。 リダイレクト元 リダイレクト先 雑感 307はメソッドと本文を変更することが禁止されているため、リダイレクト元と同様のリクエストをリダイレクト先に送信することができます。 303はリダイレクト元にPOSTでアクセスすると、リダイレクト先ではGETメソッドでアクセスします。 ※ ただしHTTPクライアントが実装できてるかどうかは別の話です。 ちなみにcurlで303リダイレクトすると、リダイレクト先も本文つかないけどPOSTメソッドでアクセスしちゃうし、 BurpSuiteのRepeaterだと307はリダイレクト先をGETメソッドでアクセスしちゃう。。。 HTTPクライアント全てが303,307を意図した挙動で動作させるわけでもないみたい。 (実装が悪いのか僕の使い方が悪いのかはわかんないけど) おしまい。 »

Mac AppStoreのキャッシュを削除する

新年あけましておめでとうございます。 昨年はアウトプットの場をLTや登壇をメインにしていたので、ブログの投稿数はだいぶ少なめでしたが、今年はブログでのアウトプットも頑張っていきたいと思ってます。 実は、最近まで手持ちのMacをElCapitain(10.11)でずっと利用していました。 アップデート後、スリープ復帰後にBluetoothとWifiの接続が切れて一定時間使えない、特定のアプリケーションが動かない等いろいろ問題を抱えていたので上げるに上げ切れず… しかし、Docker for Macのアップデート後、10.12以降でないと動作しない問題が発覚し致し方なくMojave(10.14)までアップデートを実施することに。 加えてXcodeのアップデートも実施していましたが、途中誤ってMacをスリープさせてしまい、以降アップデートのプログレスバーが進まなくなりました。 再起動して再度ダウンロードしても、プログレスバーが動作せず、Wiresharkでパケットdumpしてもダウンロードが進んでる様子が無い… のでおそらくダウンロードキャッシュが壊れてるのではないかと推測。 思い切って、ダウンロードキャッシュを削除することに。 Terminalからコマンドを入力しディレクトリを開く $ open $TMPDIR../C/com.apple.appstore/ 数字の羅列があるディレクトリ内にflyingIconがあるので確認して、削除したいアプリケーション(今回はXcode)のアイコンであればディレクトリごと削除する。 そしてAppStoreを再起動して、再度アップデートを開始する。 これで再度ダウンロードができる。 しかし、最初からのダウンロードになるのでXcodeとか6GBくらいあるアプリだと結構辛い。 参考 Clear Mac App Store Temp Cache to Fix Some Download Issues - OXSDaily AppleDeveloperForums »

[Mac]GoogleChromeのXSSAuditorを無効化する

GoogleChromeで脆弱性診断をやってる時や、やられサイトの作成をしてる時に XSSのテストをしていると止められてしまうため何か良い方法はないかとググってたら ちゃんとやり方があった。 $ open Google\ Chrome.app --args --disable-xss-auditor XSSAuditorを無効化するオプションをつけて起動するだけでOKでした。 »

jythonでtimestampを取得する方法

久々の投稿です。 最近は、脆弱性診断がメインで以前のようにコード書いたり、 インフラをがっつりやることは減りましたが楽しくやってます。 脆弱性診断ではBurpSuiteを主に利用しているのですが、 標準の機能では診断が困難な場合はExtensionの作成が必要になります。 例えば、HTTPリクエストヘッダにシグネチャを追加しなければならなかったりとか… ですね。 シグネチャに現時刻のタイムスタンプが使われていて、シグネチャを再生成する必要があったのですが、 JythonでExtensionを作成する際にハマったのでそのときのメモ。 Python2.7で現時刻のtimestampを取得する際はこう書いてました。 >>> from datetime import datetime >>> datetime.now().strftime('%s') '1538760310' しかし、Jython2.7で上記のコードを動かすと’%s’がまんま出力されます。 >>> from datetime import datetime >>> datetime.now().strftime('%s') '%s' あらら… と思ってJythonのドキュメントをみると’%s’が無いんですね。 8.1.7. strftime() Behavior - jython.org じゃあPythonにはあったのか?とPython2.7のドキュメント見ても無いんですね。 8.1.7. strftime() Behavior - docs.python.org いつから使えるようになっていたのだろうか。dateコマンドでは’+%s’があるのでPythonでも使えるだろうと思い雰囲気で使ってました。 jythonで’%s’が使えなくて困ってたので、timeライブラリを読み込んでmktimeで処理することに >>> from datetime import datetime >>> import time >>> str(int(time.mktime(datetime.now().timetuple()))) '1538761554' 一度intで囲んでるのは、mktimeするとfloat型で出てくるため。 ドキュメント読めば最初からハマらなかったんですが、’%s’使えないとは盲点だった。 おしまい。 »

unicodeとutf-8を変換するAlfred Workflowを書いた

最近、転職と一人暮らしの生活が始まり いろいろ大変だったのですが、 落ち着いたので久々にブログを書く。 お仕事はセキュリティ関連なのですが、 通信を見ると日本語のメッセージがunicodeで流れてくることもしばしばあって CLIやWebアプリで変換して読んでたりしてました。 通信を見るツールと画面を行ったり来たりするのも結構しんどくて どうにかしたいけど、 そのツールが日本語弱いので プラグイン書いて頑張るのもなあと思い そこで、普段から使ってる Alfredでunicodeとutf-8の変換ができるプラグインを書きました。 Alfredは、Macで使えるランチャーで 有料版を買うとExtensionの使用が可能になります。 実際に作ったのは下記です。 uto8 - 328 全てランチャー完結するので、画面の切り替えが発生せず いい感じに作業ができるようになりました。 ちなみに unicodeからutf-8, utf-8からunicodeの相互変換と クリップボードへのコピーも可能です。 おしま。 参考 PHPでユニコードエスケープ - はて日記 »

ngrokを利用して開発環境をグローバルに公開する

ngrokを利用して開発環境をグローバルに公開する 1年前くらいから利用してたんですが、最近また調べてたので メモ書きとして残す。 ngrokはNATやFW以下にあるローカル環境を、 インターネット越しアクセスが可能にできるサービスです。 開発環境で作成したWebアプリケーションを、 ちょっとだけインターネット越しに誰かに見せたい時とか、 APIの検証でどうしてもグローバルに出さないといけない場合 (例えばTwilioでローカル環境のTwimlを読ませたい時とか)があって ちょっと見せたいだけなのに、 AWSにインスタンス立て公開するのも少し面倒なので どうやろうか悩んでいた時にngrokを見つけました。 ngrokはbrewで入れたりできるので導入はすごく簡単です。 v1のときは無料でsubdomainを固定化できたんですが、 v2から有料オプションになっちゃったようで少し残念です。 あとは、扱えるセッション数が限られているので、 2人で同時アクセスしたりすると片方弾かれたりします。 それだけ聞くと不便な感じもしますが、 特定の人にちょっとだけ閲覧できるURLを作成して公開する分にはとても便利です。 インストール方法とか、扱い方とかはいろんなサイトで紹介されてるし 公式サイトのDocsにも載ってるので割愛しますが、 ngrokコマンド実行時にregionの指定だけやっておいたほうがいいです。 それか、~/.ngrok2/ngrok.ymlに記述しておく。 $ ngrok http 2280 --region=ap ドキュメントにも書いてあるんだけど、デフォルトはusになっています。 なので、全ての通信がus経由になってしまうため ngrokから発行されたURLからアクセスするともっさり感すごいです。 ちなみに今は、us, eu, ap, auの4リージョン選べるようです。 あとは、企業ネットワークから使う場合は ちゃんとセキュリティポリシーの確認をしましょう。 あとでセキュリティチームに怒られる可能性もあります。 あとは、開発環境のデバッガーをうっかり 上げたまま公開するのも注意が必要です。 過去にCakePHPでDebugKitを有効にしたまま公開しちゃって 環境変数に埋め込んだキーを取っ替える作業が 発生したりしたこともあったので…^^; »

Twilio Copilot使ってSMSの再送処理を減らした話

先日参加したJAWS DAYSでTwilioUGの方々とお話する機会があって、 TwilioのCopilotの事例がまだ少ないとのことだったので、書いてみる。 ブログでは、Twilioの話題を出したことは無いんですが、 Twilioを使ったSMS配信サービスと音声発信のサービスやってます。 SMSだけで言えば毎月5,000 ~ 7000件くらい、 音声発信もだいたい5,000件くらいでしょうか。 当初、SMS配信サービスを作った時に、 SMSのfromをTwilioで購入した電話番号にしていました。 利用数が増えるにつれ、「fromを文字列にしたい」という要望が出てきました。 他サービスでは、fromを番号ではなく英文字の送信者番号として送信しているものがあり、 どうしたら良いのかと考えていました。 SMSには「Alphanumeric Sender ID」というものがあり、これを使えば 実現できるものだと分かったため、さっそく実装を始めました。 これが2017年3月くらいだったかな。 テストの段階で気づいたんですが、Alphanumeric Sender IDだと受信できない端末?キャリア?も多く、 APIでPOSTするタイミングで、エラーコードの「21612」が返されることがありました。 error 21612 - twilio Alphanumeric Sender IDで送りたいのだけれど、 SMS配信のサービスやってるのに 相手に届かないのはサービスとして困るので 英文字の送信者番号で送れなかった場合は、 Fromを番号で送信リトライするという処理も入れていました。 リトライを処理を入れてから、 数ヶ月様子を見てどれぐらいエラーコード「21612」が返されてるかを確認していました。 下記は、とある1ヶ月間での統計です。 SMSをAlphanumeric Sender IDで送信できた数 : 3500件 SMSを電話番号で送信できた数 : 1500件 (リトライ処理で送信した数) この数字を見ると、だいたい30%近くのリトライ処理をやっています。 キャリア別で見ると、リトライ処理をしている番号は auと沖縄セルラーの番号が半数超えていました。 auと沖縄セルラーが多いのは地域事情だと思いますが、 それにしても他キャリアに比べてSender IDで送れない場合が多かった。 1500件のリトライ処理もそこそこ多くて、この辺りをなんとかしたいなあと思ってました。 真面目に自分で実装するなら、Alphanumeric Sender IDで送信できなかったものをDBなりでリスト化しておいて 送信のたびにリストをチェックして、番号で送るかAlphanumeric Sender IDを利用するかを決定すれば実装できそうです。 ToとFromをマッピングしたテーブルを用意しておく感じですね。 ただ、日に日に増えてくるデータからマッピングを自分たちでやるのはヤダなあという感じもしてて、 どこかに任せたいと考えていたところ、Copilotに出会いました。 Copilotは、複数の番号をまとめて管理しSMSを効率良く配信できる機能を備えています。 サービスとして特にリアルタイム性を求める配信はしてないのでそこに魅力を感じてはなかったんですが、 Alphanumeric Sender IDと番号を登録しておけば、 »