DNSブロッキングは筋が悪いのか？:Geekなぺーじ
日本で行われている児童ポルノブロッキングで採用されているのは、DNSキャッシュサーバがブロックリストに掲載されたFQDNの名前解決を行わないという、DNSキャッシュポイズニングという手法です。 この手法は、主にISPが提供するDNSキャッシュサーバにて行われているので、児童ポルノブロッキングを行っていないDNSキャッシュサーバを利用することで回避が可能です。 また、IPアドレスを直接指定して通信を行うことで回避することも可能です。 このような手法が採用されていることに関して、「アホじゃないの？」とか「ザルじゃないの？」という感想が述べられがちです。 昨日、以下のような記事が出ていましたが、それに対しても「仕組みを考えた奴はバカだろう」的なニュアンスの感想が散見されます。 児童ポルノ遮断、「ＩＰ直打ち」ですり抜け横行 : 社会 : YOMIURI ONLINE（読売新聞） 私の感想 「IPア
フォーム自動入力(x-autocompletetype)の実験
※ご注意： ウイルスバスターがインストールされている環境だと、この記事は読めないようです (→参考画像) (x-autocompletetypeとは？) Webサイトのフォームにワンクリックで個人情報を自動入力してくれる便利機能。ブラウザに、あらかじめ名前やメールアドレスや住所やクレジットカード番号などの情報を設定しておく。 アンケートサイトとかに超便利 入力が苦手なオカンも便利 とにかくべんり Google Chrome のみ対応してる (2012年4月4日時点)。 便利すぎて今後、他のブラウザも追随必至。 (ユーザーが自動入力を使うには) Google Chrome 設定 → 個人設定 → 自動入力設定の管理 → 住所氏名メールアドレス等を入れておく (Webページ側での自動入力の設定) inputにx-autocompletetype属性をつけて、値を email とか sname
処理開始後の例外処理では「サニタイズ」が有効な場合もある
このエントリでは、脆弱性対処における例外処理について、奥一穂氏(@kazuho)との会話から私が学んだことを共有いたします。セキュアプログラミングの心得として、異常が起これば直ちにプログラムを終了することが推奨される場合がありますが、必ずしもそうではないというのが結論です。 はじめに Webアプリケーションの脆弱性対策では、脆弱性が発生するのはデータを使うところであるので、データを使う際の適切なエスケープ処理などで対処するのがよいと言われます。しかし、処理内容によってはエスケープができない場合もあり、その場合の対処についてはまだ定説がないと考えます。 エスケープができない場合の例としては、以下があります。 SQLの数値リテラルを構成する際に、入力に数値以外の文字が入っていた メール送信しようとしたが、メールアドレスに改行文字が入っていた 入力されたURLにリダイレクトしようとしたところ、U
github の mass assignment 脆弱性が突かれた件
Github に脆弱性。やった人は Rails に有りがちな脆弱性を issue に挙げていたが相手にされず、実際にそれを突いてきた。一見 childish だが、それだけ簡単に脆弱な実装がなされてしまうということだ。週明けの今日、Rubyist はまず関連情報に一読を。 — Yuki Nishijima (@yuki24) March 4, 2012 気になって調べたのでメモ。自分も気をつけないとなー。 Public Key Security Vulnerability and Mitigation - github.com/blog/ github に脆弱性があってそれが突かれたらしい。 Rails アプリにありがちな脆弱性の一つ、Mass assignment とかいうタイプの脆弱性である。 mass assignment 脆弱性とは mass assignment 脆弱性とは何か、
Windowsに潜むデフォルト設定の落とし穴（中）
表3を見てほしい。これらの情報が何かわかるだろうか。この表は，ポート137から取得できる主な情報を列記したものである。Windowsの137番ポートに対して，接続の状態を問い合わせるパケットを一つ投げただけで，このような情報が取得できてしまう。返ってきたパケットが，これらの情報を含んでいるのだ。 具体的には，そのパソコンのコンピュータ名やログオン・ユーザ名に加えて，そのパソコンがドメイン・コントローラやマスタ・ブラウザになっているか，ファイル・サーバとして機能しているか，Internet Information Server/Services（IIS）やSambaが動作しているか，さらにLotus Notesが動いているかなどの情報が取れる。SecurityFriday.comのMichiharu Arimoto氏によると，「コンピュータ名のほか，IISやドメイン・コントローラ，マスタ・ブ
確認画面でhiddenに入力値を埋め込むのはセキュリティ的にダメか? | ブログが続かないわけ
お礼 先のエントリー(初心者プログラマーが簡単なフォームを作るときにやりがちな6つのミス)で、自分でもびっくりするくらいのブックマークを頂いた。この内容が参考になると思ってブックマークしてくれた人より、他の人にも紹介したいとか、よくあるよねといった共感に近い気持ちでブックマークしてくれた方が多かったのは、素直にうれしいしと思ったし、安心もした。 本題 ただ、何人の方から「確認画面でhiddenに入力値を埋め込むこと」に対して疑問を抱かれた。これに対して僕なりの解釈を付け加えておきたいと思う。 以下は、あくまでもフォームの話。 セッション管理されたシステム内におけるなんらかの書き込みシステムでは、話が全く変わってくることにご注意を。 結論から言うと「確認画面でhiddenに入力値を埋め込むこと」はセキュリティ的には問題ない。 (以下、この方法をhidden方式と呼ぶ) そもそも、セキュリティ
mixi足あと廃止に寄せて - 最速転職研究会 | コメント mixiって今ほとんどがモバイルでアクセスされてたはずだけど、スマホ以外のガラケーでもこの問題が起きるの？
mixiが6年以上に渡って放置してきた足あと機能を使って訪問者の個人特定が可能な脆弱性を修正した。簡単に説明するとmixi以外のサイトからでもユーザーに気付かれずに、その人のmixiアカウントを特定するということが出来たが、出来なくなった。(正確にはユーザーが気付いたとしても特定された後) アダルトサイトが訪問者のmixiアカウント収集したり、ワンクリック詐欺サイトがmixiアカウント特定して追い込みかけたり、知らない人からメッセージ送られてきてURL開いたらmixiアカウント特定されてたり、そういうことが今まで出来ていたのが出来なくなった。 過去にもいろんな人が言及してるし、すでに終わった議論だと思ってる人もいるだろう。世間一般にどれぐらい認知されていたのかはよく分からないが、少なくとも技術者やセキュリティ研究者の間ではよく知られている問題だった。 http://internet.kil
本当は怖い文字コードの話 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
さくらのVPSに来た攻撃観察記
Engadget | Technology News & Reviews
セキュリティガイドライン
HTML5 Security Cheatsheet
紙だけでサイトごとに異なるパスワードを生成する暗号、米研究者が考案