LINE Developer Meetup in Fukuoka #16 http://connpass.com/event/38413/
![実例に学ぶXSS脆弱性の発見と修正方法/line_dm 16 20160916 how to find and fix xss](https://cdn-ak-scissors.b.st-hatena.com/image/square/e11e4f3633c4a4b47615102c364a08e3fe6bc717/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F42f96bfa19aa47c2b5e2bf59d2b24a82%2Fslide_0.jpg%3F6898712)
LINE Developer Meetup in Fukuoka #16 http://connpass.com/event/38413/
先日もtwitter上の犯行予告により20歳の青年が逮捕されたようですが、なりすましによる誤認逮捕ではなかったのか気になるところです。そこで、twitterが、なりすまし投稿をどの程度対策しているかを調べてみることにしました。twitterの安全性を確認することが目的というよりも、twitterが実施している対策を知ることにより、皆様のWebサイトを安全にする参考にしていただければと思います。 今回調べた「なりすまし投稿」の手法は下記の通りです。 クロスサイト・リクエスト・フォージェリ(CSRF) クロスサイトスクリプティング(XSS) HTTPヘッダーインジェクション クリックジャッキング DNSリバインディング クッキーモンスターバグ このうち、上の5つの解説は拙稿「“誤認逮捕”を防ぐWebセキュリティ強化術」、最後のクッキーモンスターバグについては、過去のエントリ「クッキーモンスター
もう10年以上前のネタなのですが、いまだに有効だし、最近、セッションを扱っていないならXSSがあってもあまり問題ないという意見を見ることがあるので、サービス提供側として案外面倒なことになる場合がある、という話を書きました。 POCです。 http://www.udp.jp/misc/largecookiedos.html 内容としては、 JavaScriptから巨大なCookieをブラウザに設定できる HTTPサーバーは受け取れるHTTPヘッダーサイズの上限を持っていて、それを超えていた場合にBad Requestを返す 1によって2を超えるサイズのCookieが設定可能な場合がある(たぶんほとんどの場合可能) よってXSSなどによって巨大なCookieを設定されると以降サービスが利用できなくなる というものです。 Cookieの有効期限を何十年も設定されるとユーザー側で勝手に回復すること
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
今回は、そのかんたんログインの問題点について説明します。 「契約者固有ID」を用いるかんたんログイン かんたんログインとは、携帯電話の「契約者固有ID」を用いたログイン手法です。 第1回で説明したように、携帯電話のブラウザのリクエストヘッダには契約者固有IDと呼ばれるIDを付けることができます。契約者固有IDは、携帯電話事業者によって詳細は異なりますが、すべての携帯電話事業者が対応しています。 図1は、NTTドコモの携帯電話がサポートしている契約者固有IDである「iモードID」がサーバに送信される様子です。この情報は、ユーザーがそれと意識することなく送信されます。携帯電話のかんたんログインとは、契約者固有IDのみを用いて認証を行い、ログイン機能を実現することです。 かんたんログインは、ベーシック認証のようにIDとパスワードを管理する必要もなく、Cookieのように対応する端末を考慮する手間
OpenSocial周りの調査をしていると、Cajaという言葉に遭遇します。セキュアなJavaScriptを実現するもの、ということだけ分かっていたのですが、詳細を調べてみました。 クロスサイトスクリプティングとブログパーツ gooやlivedoor、fc2などのホスティングを含めたブログサービスを使ったことのある方はご存知と思いますが、サービスによってブログパーツが貼れるもの、貼れないもの、一部だけ許可しているものがあります。なぜでしょうか? Cookieには同一ドメインから実行されたスクリプトしか参照できないという特徴があります。これを利用して、Cookieをセッション情報や閲覧履歴の保存場所として活用しているサービスは少なくありません。上記ブログサービスがブログパーツを許可しないのは、これらの情報を悪意のあるJavaScriptから守るためです。逆に言うと、同一ドメイン上でJavaS
そしてcookieを奪うのがどれほど簡単かというのは、CSRFの事例が後をたたないことからも伺い知ることができる。 うーむ、CSRFの理解って結構浸透してきたと思っていたのですが、そうでもないようで……。 CSRF は Cookie を奪取してセッションハイジャックするような攻撃ではなく、攻撃者は Cookie の値を知る必要がありません。また、CSRF 攻撃によって攻撃者が Cookie を奪取することもできません。もちろん、別途 XSS があったりすれば Cookie を奪取できる余地がありますが、それは XSS による漏洩ということになるでしょう。 それから、User-Agent の一致チェックは対策としては不十分です。というのも、CSRF では原理上 User-Agent が一致するに決まっていますし、Cookie 奪取を想定するなら、攻撃者が User-Agent を一致させるこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く