葉っぱ日記スマートフォン用の表示で見る葉っぱ日記この広告は、90日以上更新していないブログに表示しています。2019-03-12alertを出したいんだ俺たちはJavaScript利用者に対してメッセージを意識的に伝えたり、あるいは何かしらの行動を促すために、ダイアログボックスを表示するための機能がブラウザーには複数実装されている。して、その手の機能を以下にまとめた。任意のメッセージが表示可能。繰り返し表示される場合にそれを抑止する機能がほとんどのブラウザーに実装されている。任意のメッセージが表示可能。任意の1行テキストが入力できる。繰り返し表示される場合にそれを抑止する機能がほとんどのブラウザーに実装されている。任意のメッセージが表示可能。OK、キャンセルのボタンを持つ。繰り返し表示される場合にそれを抑止する機能がほとんどのブラウザーに実装されている。任意のUIをHTMLで作成可能。メソッドを呼び出して明示的にダイアログを閉じるまでHTML内への操作はできない。一部ブラウザーでのみサポートされている。HTTPで401応答を返すことで表示されるログインダイアログ。realmで指定可能な文字種が限定的であり、またrealmで指定した文字列が表示されるブラウザーと表示されないブラウザーがあるため、任意メッセージの表示には不向き。繰り返し表示を抑制する機能はないため、何度も繰り返して表示させない方がいい。することで表示される、印刷を促すダイアログ。任意メッセージの表示はできない*1。多くのブラウザーではウィンドウモーダルで表示されるため、他のタブに切り替えてそのページを閉じるということは難しい。繰り返し表示を抑制する機能はないため、何度も繰り返して表示させない方がいい。すると、外部のアプリに切り替えていいかのダイアログが表示される。任意メッセージの表示には不向き。ウィンドウモーダルで表示されるため、他のタブに切り替えてそのページを閉じるということは難しい。繰り返し表示を抑制する機能はない。Hostというプロセスが起動する。ダイアログを閉じていなくても複数のダイアログを連続して表示可能。これらの特徴から、ループ内から繰り返しダイアログを表示するのは非常に煩わしいため、そのようなコードは避けた方がいい。他にも色々あるけれど、とりあえず人間に対して任意のメッセージを伝えるにはalertがいちばん使いやすいのでこれからも積極的に使っていきたいところ。コミックマーケット93向けに本を書きました@nash_fsさんに誘われて、明日のコミックマーケット93で合同誌「WebMix」に記事を書きました。ローカルネットワークに対するクロスオリジンの攻撃からシステムを守る簡単な方法インターネット上に公開されているわなサイトを経由して社内イントラネットなどのローカルネットワークへXSSやCSRFなどのクロスオリジンでの攻撃を仕掛けようという試みは古くから存在します。現実にこれらが行われたという話は聞いたことはありませんが、理論上は可能であるという話をよく聞きます。対策としてまず検討すべきは、社内システムであっても通常のシステム同様に脆弱性を生まないようセキュアなものにするということです。それらが難しい場合には、少しの手間でローカルネットワークに対するクロスオリジンでの攻撃を低減させることができます。Rules...」をクリックします。エディターが立ち上がってルール用のFiddlerScriptの編集画面が出てきますので、以下を追記します。}}たったこれだけで、外部のわなサイトを経由したクロスオリジンの攻撃からローカルシステムをある程度守れます。まとめやっていることは、通常は社外の公開サーバーをRefererやOriginとして社内に対してリクエストが発行されることはないので、それを検知した場合に404応答を返しているだけです。ことながら、ReferrerやOriginがつかない状況も頻繁に発生するので、そういった場合にはこの方法では攻撃を防ぐことはできません。繰り返しになりますが、社内システムであっても社外のシステム同様にきちんと脆弱性への根本的な対策を行っておくべきでしょう。バグハンター合宿に参加してきた。connpass3年前は個人戦だったけれど今回はチーム戦ということに加え、クソつまらない脆弱性を多数報告した場合は評価が下がる採点方式だったので、最初はチームの足を引っ張らないようホームラン級のバグを探そうとしたけれど、最近すっかり技術的なことをやっていないのでなかなかそういうバグも見つけることができず、ゼロよりマシだろうということで結局わりとくだらないバグをいくつか報告した次第。いえ、他の人はあまりやらないだろうなという「クロスオリジンでの情報漏えい」みたいな自分としては好きなタイプのバグをひとつ見つけて報告することができたので、その点は満足。結果的にチーム順位は最下位、個人順位ではかろうじて10位に入るという感じでした(下から数えた方が早い)。Kinugawaさん強すぎ。いろんな攻撃手法に関して、以前なら自分の技として適切な場面でそれを取り出して使えることが多かったけれど、だんだんと手を動かす時間が減るにつれ他の人の攻撃例を見て「ああ、そうか。そこでその攻撃手法が使えたんだ!」みたいな感覚になっていってたんだけど、さらに今回は「なにそれ。そんな攻撃方法あったのか」みたいに全く知らない技がいくつもあったりして、すっかり時代においていかれた感を味わってきた。実際にサイトを検証するのは、CTFと違って「問題のための問題」みたいなのではなく、実際に生きて動いてるWebサイトなのでどれだけ不合理で不自然なかたちであっても脆弱性が存在すればそれは現実のものなわけだし、あるいは特定の挙動についてあるサービスではサービスの提供方針として脆弱性として認定されるものが他のサービスでは脆弱性とは認定されないというような運用指針に寄るものがあったり、そういう点でリアルな世界なので学びも大きいし超楽しかった。次回が開催されるのかはわからないけれど、もし開催されるのであれば次は事前にちゃんと予習復習をして、もうちょっと人権をちゃんと確保したい。セキュリティの『アレ』http://tsujileaks.com/media/are_170423.mp3人に聞かせるために話すっていうよりは、辻さん根岸さんに解説してもらいながら3人との会話を自分自身が楽しむみたいな感じでした。2016」16日目の記事です。具体的な脆弱性の話でなくてすみません。コードを書いていると、安全に脆弱性を発生させたくなるときがあります。書くとさっぱり意味がわからないと思いますが、セキュリティの講義のための演習環境とかそういうやつです。受講生自身の手でWebアプリケーションの脆弱性を探してもらうような演習では、検査対象となる脆弱性を含むWebアプリケーションを用意する必要があります。ようなものを代表にいくつかのものがありますが、これらはUIが英語であったり、あまりにもメジャーすぎて受講生も触っている可能性があったりと、場合によっては利用が難しいことがあります。単一のWebサーバに対して複数の受講生が一斉に検査を行うような講義形態を採る場合(各自が手元でVMを立てて一人で検査を進めるよりも、同じサーバに全員でアクセスするほうが講義が盛り上がるのです)、環境に対して破壊的な脆弱性が存在していては演習そのものが中座してしまう可能性があります。そこで、こういった講義を行う際には私はその講義の受講生のレベルなどに合わせて調整した脆弱なWebアプリケーションを都度自分で書いているのですが、そのときに「脆弱性があっても安全になるように」いくつか気を付けている点があります。今日はそういった点についてメモ書きとして記しておきます。SQLインジェクションではデータベースを破壊できないよう読み取りのみに制限しておく以前、演習の早い段階で参加者の一人がSQLインジェクションで他の参加者のパスワードを変更してしまったために他の参加者は演習を進めることができなくなったということがありました。それ以降は、SQLインジェクションを仕込むときにはデータベースの読み取りはできるが更新や削除といった破壊的な操作はできないように権限などを適切に設定する等の対策を行ってSQLインジェクションを含ませるようにしています。いうのを組みあわせて、ログインすると直後に強制的にログアウトさせられてしまうという罠を参加者が仕込んだことがあり、その場合もやはり演習がそれ以降進まなくなってしまいました。CSRFを仕込む場合にはCSRFによって機能が呼び出されたとしても以降のユーザー操作に影響を与えない、例えばお問合せフォームの送信やニックネームの変更など、といった個所に限定するようにしています。XSSもCSRF同様にユーザーの妨げにならない個所に限定するXSSを仕込んでおく場合も、CSRF同様に仮に悪用されてもユーザーの操作の妨げとならないような個所だけで発生するようにしておきます。XSSの発生する個所をユーザー操作の必要な個所に限定する、蓄積型のXSSであっても例えばそのメッセージを開く前に削除できるようにする、といった感じです。OSコマンドインジェクションは入れないOSコマンドインジェクションは環境を破壊してしまう恐れが強く、特に参加者がそのことを把握していないような場合には何が起こるかわからないので、基本的には脆弱性としては含ませないようにします。攻撃者の用意したセッションIDを利用者に強制させるセッションアダプションはユーザーによって回避可能であり操作不能となるようなことがないため、実装上無理がない限りは脆弱性として積極的に取り込んでいきます。オープンリダイレクタも積極的に採用たいていの場合、オープンリダイレクタも演習の妨げとなるような致命的な問題が発生しにくいため、積極的に組み込んでいきます。そのリダイレクタが永続的かつユーザーの操作なしに有効となってしまいユーザーが以降の演習ができなくなるといったような個所には絶対に含まれないように注意が必要です。対象となるWebアプリケーションにそれっぽいセキュリティポリシーの文面を掲載しておき、例えばそこに「このサービスは通信経路上が暗号化されているため安心してご利用頂けます」等を記載しつつhttpでアプリケーションをサーブするといった、技術的でない脆弱性を含ませておきます。これは他の脆弱性と違い環境を破壊されないので安全であり安心してサービスを提供できます!これ以外にも「HTMLコメントやJSコメントに機密情報(らしきもの)を記載しておく」といった小さな脆弱性を含ませることもあります。さんにサーバ上で電卓を立ち上げられてしまうことがあったりと、なかなか世の中難しいなというところです。2016」11日目の記事です。昨日のネタの続きです。昨日は30x応答のレスポンスボディを表示させるために21/tcpなどへのポートへリダイレクトさせるという方法を紹介しました。Firefoxではレスポンスボディを表示させるそれ以外の方法として、CSPを使うという方法があります。リダイレクタページを埋め込みます。src="http://page1.example.jp/redir?q=http://page2.example.jp/?&quot;><script>alert(1)</script>"></iframe></iframe>攻撃者のサイト上ではCSPによりframeとして表示可能なコンテンツがhttp://page1.example.jp/上のリソースに制限されており、iframe内ではpage1.example.jpを読み込んだ時点でpage2.example.jpへのリダイレクトが発生しますが、リダイレクトはCSPにより失敗し、結果としてpage1.example.jpのレスポンスボディが表示され、page1.example.jp上でのXSSが成立します。いうわけで、昨日に引き続き30x応答のレスポンスボディでもXSSを成立させるための方法を紹介しました。このように、30x応答でもXSSが存在していた場合には攻撃を成立させることができますので30xだからと油断せずにきちんと対策が必要です。昨日および本日の「30xリダイレクトのレスポンスボディでもXSS」ネタは、sec-testing.slack.comで教わりました。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。