駆け出しエンジニアの皆さんに知ってほしい脆弱性のこと。
セキュリティは難しいです。 ですが、プログラミング初学者の皆さんは必要以上に萎縮せず、どんどんアプリケーションを作り、公開することにチャレンジして欲しいと私は思っています。 一方、事実として、脆弱なアプリケーションが公開されている（サーバ上でアクセス可能な状態になっている）だけで、全く無関係な第三者が被害を被る可能性があることは知っておく必要があります。 それはWordPressを使った単なるWebサイトであったとしても同じです。 また、あなたのアプリケーションが破壊されて困らないものであったり、 個人情報を保持していないものであったとしても、です。 だから、知らなかった、では済まされないこともあります。 この記事では、PHPのソースを例に、 特にプログラミング初学者が生み出しやすいアプリケーションの脆弱性について、 具体的なコードを挙げながら解説します。 なお、本記事のサンプルコードはも
Mozilla Foundation セキュリティアドバイザリ
現在地: セキュリティセンター > Mozilla 製品における既知の脆弱性 Mozilla 製品における既知の脆弱性 このページには、Mozilla 製品の特定のバージョンに影響を及ぼすことが知られているセキュリティ脆弱性のリストと、ユーザが自分自身の身を守るためにできることについての説明が載っています。新しいセキュリティの問題が見つかった場合は、このリストに追加されます。製品やバージョンごとに分類されていない完全なリストは Mozilla Foundation セキュリティアドバイザリ をご参照ください。 私たちがこれらのバグをどう取り扱うかについては mozilla.org のセキュリティバグ指針 をお読みください。もしこのリストに未掲載で公開の Bugzilla バグ として登録されていないセキュリティの問題を見つけたり、このリストに間違いや矛盾を見つけたら、私たちにメールで情報提
Firefox セキュリティアドバイザリ
重要度の区分け: 最高: 任意のコードを実行したり、ソフトウェアをインストールすることが可能な脆弱性で、通常のブラウジングの範囲を超えるユーザの操作を必要としないもの 高: ユーザが訪れた他のサイトから機密データを集めたり、それらのサイトにデータやコードを注入することが可能な脆弱性で、通常のブラウジングの範囲を超えるユーザの操作を必要としないもの 中: デフォルトではない特殊な設定を行った場合のみ攻撃可能であったり、複雑な操作や思いも寄らない手順を必要とする点を除けば、「高」または「最高」に分類されるであろう脆弱性 低: サービス妨害 (DoS) 攻撃、少量のデータの漏えい、なりすましなど、比較的重要でないセキュリティ脆弱性 (SSL 利用サイトの検知不可能な偽装は、たいていの場合、他のサイトで入力されるはずの機密データを盗み取るために利用されるため、「高」に分類されます) Firefox
Evernote XSS事件のエクスプロイトとその対策過程と顛末 | uuu
Evernoteに任意のHTMLを注入できる脆弱性がありました。 http://togetter.com/li/125281 Evernoteのセキュリティポリシーとかには触れず、とりあえず何が可能だったのか、どういう状況だったのかを書きます。 4/18 16時ごろ Evernoteの登録ページのHTMLに以下のような記述があります。 <script type="text/javascript"> $(document).ready(function() { suggestedTags = []; suggestedNotebook = ""; sourceUrl = ""; providerName = ""; payload = { "user" : { ... }, ..後略.. </script> このsourceUrl = ""の部分、https://www.evernote.c
高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest（ヘッダおよび、POSTの場合はボディを含む）を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse（ヘッダおよび、HTML）を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）対策がいまいち進まなかったのはなぜか
■ クロスサイトリクエストフォージェリ（CSRF）対策がいまいち進まなかったのはなぜか 4月27日の日記「クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法」で、 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古くから存在したこの問題がなぜ今まであまり注目されてこなかったかについて考えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 と書いた。あれから2か月以上が経ってしまったが、今書いておく。 端的に言えば、「CSRF対策は所詮、荒らし対策にすぎない」 と考えられてきたためではないか。 荒らし対策をするしないは運営者の自由 あるサイトに脆弱性を発見した者が、その運営者に対してその脆弱性を直して 欲しいと希望することが、どのくらい妥当かというのは、その脆弱性によって 生じ得る危険性の種類によって異なる。 たとえば、IPA の脆弱性届出状
おさかなラボ - CSRF対策法と効果
自分でもう一度整理するために、他のサイトに倣って現在挙げられているCSRF対策法とその効果を列挙してみる。ざっと書いたので多分ツッコミどころ満載だと思うがとりあえず公開。現在思いつく最善解は一番下に書いた。あとは順不同。 POSTを用いる 推奨: とりあえず 効果: あり 回避法: あり(Javascriptによる自動Submitなど) 実装: 簡易 副作用: なし 確かにPOSTでのCSRFを破る手法は存在するが、だからといってこの対策に全く効果がないわけではない。完了画面への直接リンクでのCSRFの発生は抑制できる。実装が簡単な上、副作用が特にないので実装しておいて別に損はない。 リファラ(Referer: ヘッダ)をチェックする 推奨: ケースバイケース 効果: 大 回避法: 特になし 実装: やや難(コードに汎用性を持たせるのが難しい) 副作用: ブラウザ
Spare Clock Cycles
Google Analytics XSS Vulnerability This post documents an XSS vulnerability I discovered in the event tracking functionality provided by Google Analytics. Given a website's Google account number (which can be found in the site source), one could spoof specially crafted events that, when clicked in the administrative interface, would run arbitrary Javascript in the victim's browser. This would allo
それ Unicode で
UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ちょっと難しい目のXSSの練習問題を作りました。 - 葉っぱ日記
セキュリティ＆プログラミングキャンプのCTFで出題したXSS問題 - 葉っぱ日記