高木浩光＠自宅の日記 - やはり退化していた日本のWeb開発者「ニコニコ動画×iPhone OS」の場合
■ やはり退化していた日本のWeb開発者「ニコニコ動画×iPhone OS」の場合 一年前、「退化してゆく日本のWeb開発者」という題で、ケータイWebの技術面での蛸壺化について次のように書いた。 iPhoneに契約者固有ID送信機能が搭載される日 （略）こうして退化してゆくケータイWebが、日本のスタンダードとなってしまい、いつの日か、PC向けの普通のインターネットまで、単一IDの全サイト送信が必須になってしまうのではないかと危惧した。 （略）iPod touchでNAVITIMEを動かしてみたところ、下の図のようになった。 （略）契約者固有IDがないとどうやって会員登録システムを作ったらいいのかわからないんじゃないのか……というのはさすがに穿ち過ぎだと思いたい。NAVITIMEからソフトバンクモバイルに対して、契約者固有ID送信用プロキシサーバの用意を要請している……なんてことがなけれ
はてなのCAPTCHAを破るプログラムは30分で書ける - やねうらおブログ(移転しました)
CAPTCHAとは、スパムコメントなどを防止するための認証画像のことである。 それにしても、はてなのCAPTCHAはひどい。無いよりマシという考え方もあるのでそれについてはあまり議論する気は無いのだが、それにしてもこれを破るプログラムは30分あれば十分書ける。 具体的には、はてなのCAPTCHAには8つの好ましくない特徴と、2つの脆弱性がある。 ■ 8つの好ましくない特徴 ・画像自体のサイズが小さすぎる。→ こんなに小さいと探索量(計算量)が小さくて済む。 ・フォントにゆがみがない → フォントはある程度変形させたほうが良い。変形させてあるとテンプレートマッチングがしにくくなる。 ・フォントが固定。→ フォントは毎回変えたほうが良い。 ・フォントを回転させていない → フォントは文字ごとにある程度ランダムに回転させた方が良い。 ・フォントサイズが一定 → フォントサイズは文字ごとにある程度
yebo blog: OpenSSHのベスト・セキュリティ・プラクティス
2009/07/27 OpenSSHのベスト・セキュリティ・プラクティス nixCraft に OpenSSH サーバのセキュリティ上のベストプラクティスが出ていたので、簡単にまとめてみる。 デフォルトのコンフィグファイルとSSHポート 説明前に前提となるコンフィグファイルの場所とSSHポートは次のとおりである。 /etc/ssh/sshd_config: サーバの設定ファイル /etc/ssh/ssh_config: クライアントの設定ファイル ~/.ssh/: ユーザの設定ファイルが入るディレクトリ ~/.ssh/autorized_keys: 公開鍵リスト /etc/nologin: root 以外でログインができない /etc/hosts.allow、/etc/hosts.deny: tcp-wrappersによるアクセスコントロール デフォルトポート: 22 #1 OpenSSH
常駐プログラム隠蔽テクニック
タスクマネージャーに任意のプログラムを列挙されないようにする方法はないだろうか？ Windowsにはプロセスという概念がありアプリケーションはそれぞれプロセス単位で動作しています。プロセスは「Ctr+Alt+Del」で起動されるタスクマネージャーで確認でき、これを見ると現時点で起動しているプロセスのすべてを監視することができます。 さて、Windows上で実行されているアプリケーションはすべてOSの管理下に置かれているわけであり、よってすべてのプロセスをOSは管理していることになります。つまりは「常駐させたいプログラムをタスクマネージャーから消し去ることは難しいのでは？」と思われるかもしれません。ということで、今回は常駐プログラム隠蔽テクニックと題してお送りしたいと思います。 私が使用したOSはWindowsXP、コンパイラはVC++.NETです。前提となる知識は、Win32API、DLL
Slowloris HTTP DoS 攻撃について
ちょっと前に Apacheに新たな脆弱性発見 - スラッシュドット・ジャパン で紹介されていた脆弱性なんですけど・・・会社のお達しで各サービス毎に状況報告ってイベントがあったので、ちょいと脆弱性試験してました。そのまとめです。 Apacheに、DoS攻撃に繋がる脆弱性が新たに見つかったそうだ（本家/.記事より） この脆弱性は、これを利用したHTTP DoSツール「Slowloris」がリリースされたことから明らかになったとのこと。この攻撃ツールはApacheに不完全なリクエストヘッダーを送り続けるもので、Apacheが最後のヘッダが送られてくるのを待つ間、偽のヘッダを送ることで接続をオープンにし続け、Apacheのプロセスを一杯にさせるものだという。 脆弱性はApache 1.x、 2.x、 dhttpd、 GoAhead WebServer、そしてSquidにて確認されているが、IIS6
UTF-8 エンコーディングの危険性 - WebOS Goodies - 葉っぱ日記
UTF-8の非最小形式による代替エンコーディングの話。古典的な攻撃方法なので、知っていて当然の話だと思っていたのですが、意外にまだ知られていないんですね。古くは Nimda の攻撃でも利用されていました…というのを調べていたら、たまたま「セキュリティホールのアンチパターン」という資料がひっかかったので紹介しておきます。あとは、ばけらさんによる説明「用語「Unicode Web Traversal」@鳩丸ぐろっさり (用語集)」がわかりやすいです。 個人的には、「UTF-8」というからには、こういうおかしなバイト列が含まれていた時点で入力全てを捨ててしまって例外などを発生させるべきで、無理やり UTF-32 とかに直すのは間違っているように思います。そうでないと、0xC0 0x32 のように、完全に壊れている UTF-8 をどうするの？とかにもなりますし。 あと、どうでもよい話： そもそもU
Unicodeで拡張子を偽装された実行ファイルの防御方法 - 葉っぱ日記
「それ Unicode で」などで紹介されている、Unicode の U+202E (RIGHT-TO-LEFT OVERRIDE; RLO)を使って拡張子を偽装された exe ファイルの実行を抑止する方法を思いついた。 メモ帳を開いて、"**"と入力する(前後の引用符は不要)。 "*"と"*"の間にキャレット(カーソル)を移動させる 右クリックで「Unicode 制御文字の挿入」から「RLO Start to right-to-left override」「RLO Start of right-to-left override」を選択 Ctrl-A で全て選択、Ctrl-C でクリップボードにコピー。 ローカルセキュリティポリシーを開く 画面左側の「追加の規則」を右クリック 「新しいパスの規則」を選択 「パス」欄で Ctrl-V をして、メモ帳の内容を貼り付ける。 セキュリティレベルが「
2008-08-06 - T.Teradaの日記 - HTTP用のページにHTTPSでアクセスする
同一ホスト上にHTTPとHTTPSのページが同居しているサイトをしばしばみます。 そんなサイトでは、本来はHTTPのページに、HTTPSでもアクセスできるようになっていることがあります。そういう場合、HTMLの中身によってはセキュリティ上の問題が出ますよという話です。 問題があるページ http://www.example.jp/index.html というURLのページがあるとします。 問題となるのは、そのページの中身に以下のようなHTMLがベタ書きされている場合です。 <script src="http://www2.example.jp/foo.js"></script> このページ（index.html）はHTTPでのアクセスを想定して作られているため、JSファイルをHTTPで読み込んでいます。 ここで、このページが実はHTTPSでもアクセス可能だとします。もしHTTPSでアクセス
Oracleでのエスケープ - 2007-12-30 - T.Teradaの日記
今日の日記では、OracleでのSQLインジェクション対策について書きます。 以下のようなコード（PHP）があるとします。 <?php ... $foo_escape = str_replace("'", "''", $foo); $sql = "SELECT * FROM table1 WHERE foo='$foo_escape'"; $stmt = OCIParse($dbh, $sql); ... 「'」を「''」にエスケープしてSQL文に埋め込み、Oracleで実行（Parse）しています。 割とよくあるコードかもしれませんが、これだとSQLインジェクション攻撃に脆弱な場合があります。 不正な文字列 DBサーバとのコネクションにEUC-JP（JA16EUCTILDE）を使用しているとします。 ここで、$fooに「[0xA1]' OR 1=1--」のような、EUC-JPとして不正な
携帯電話のリファラー（２） - teracc’s blog
多くの携帯サイトでは、GETパラメータでセッションIDの引き回しをしているようです。そのようなサイトでは、ユーザが外部サイトへのリンクを踏んだ際に、リファラーからセッションIDが外部サイトに漏れてしまう問題が指摘されています。 今日はこの問題について、思いつくことをいくつか書きます。 セッションIDの変更 奇妙に思われるかもしれませんが、単純にセッションIDを毎回変更することは、上記の問題を解決してくれます（ただし、後述するように副作用があります）。 例えば、http://www.example.com/a.cgi?SESSION=11111 にリクエストが来た場合、サーバ側ではセッションIDを変更し（ここでは22222に変更するとします）、以下のレスポンスを返すとします。 ■リクエスト GET http://www.example.com/a.cgi?SESSION=11111 HTTP
今更ながらmagic_quotes_gpcの欠点 - teracc’s blog
今更ながらですが、PHPのmagic_quotes_gpcをOnにすべきでない理由を整理してみます。 世の中には、magic_quotes_gpcはOffにすべき、と書いた文章は多数あるのですが、その理由を（私が見る限りで）十分に説明しているものは無いからです。 以下では、 1. 対象外の変数の存在 2. 弊害（副作用） 3. エスケープの不完全さ という三つの観点から記述します。 対象外の変数の存在 magic_quotes_gpcの、「gpc」はGET/POST/COOKIEを表しています。つまり、この3種類のリソースからの入力はエスケープされますが、それ以外は原則エスケープされません。 エスケープされているもの、されていないものを、以下にまとめてみます。 エスケープ済み ・$REQUEST $_GET・$_POST・$_COOKIE 場合によってエスケープ済み ・$_SESSION（
IE8のXSSフィルタが裏目に出る例 - 2009-06-22 - T.Teradaの日記
IE8のXSSフィルタは、WebアプリにXSS脆弱性があったとしても、それが発動する可能性を減らしてくれるものです。 しかし、そのXSSフィルタが裏目に出るようなこともあります。 例えば、以下のような静的なHTMLファイル（test.html）を作ってWebサーバにおきます。 <h3>ie8 test</h3> <!-- 1 --> <script> var u=document.URL; </script> <!-- 2 --> <script> u=u.replace(/&/g,'&').replace(/</g,'<'); </script> <!-- 3 --> <script> document.write('URL:'+u); </script> 上のページは静的なページで、DOM Based XSSの脆弱性もありません。ですが、被害者のユーザがIE8を使っている
C/C++ セキュアコーディングセミナー資料 | JPCERT コーディネーションセンター
これまでにC/C++ セキュアコーディングセミナーで使用した講義資料を公開しています。2010年度にセミナを実施した、文字列、整数、動的メモリ管理、書式指定文字列、CERT C セキュアコーディングスタンダード、ROSE については、それぞれ最新版の資料を掲載しています。 文字列 ユーザとソフトウエア間に発生するデータのやりとりの大部分は文字列によって行われます。 また、プログラム間でのデータ交換も文字列形式で行われるようになり、その結果、文字列表現や文字列管理、文字列操作における弱点がソフトウエア脆弱性を生み出しています。 文字列では、C/C++ 言語における文字列操作、一般的なセキュリティ上の欠陥と、その結果発生する脆弱性と対処方法について解説します。 C/C++ における文字列の特性 犯しやすい文字列操作の間違い 文字列の脆弱性 プロセスのメモリ構成 スタック破壊の仕組み コードイン
» セキュアなサーバを作るために最低限やっておくこと: エスキュービズム ラボ Blog
Recent Entries セキュアなサーバを作るために最低限やっておくこと Yahooキーワード抽出APIライブラリ テスト駆動開発 （test driven development: TDD） のすすめ GoogleAnalyticsAPI on EC-CUBE 土日で作るコンパイラ OPEN ERPに挑戦３ OPEN ERPに挑戦２ OPEN ERPに挑戦 ERPはたくさんあれど・・・ OpenGLで3D、やってみよう Recent Comments No Responses. Recent Trackbacks テスト駆動開発 （test driven development: TDD） のすすめ 06/11 » Yahooキーワード抽出... みなさんはサーバを管理するときに、何を一番気にしますか？ 人によって程度の差はあるのでしょうが、誰もが気になるのが「セキュリティ」でしょ
データベースを用いたセッションデータ管理について - LukeSilvia’s diary
Web アプリケーションとは切っても切れないセッション機構。DB ベースでセッション管理を行なって得られた知見と、それを元に考察した結果をまとめてみます。 セッションデータの特性 DB で管理される他のデータに比べ、セッションデータはかなり特殊です。主な特徴は次のような感じ。 データが増加するのが速い 定期的な削除が必要 頻繁に更新される リクエスト毎に読みに行く必要がある このデータを読めないとアプリケーション全体にアクセスできない アクセス頻度が高いということです。あと、1つ目の特徴からセッションデータについては意識的に管理してやる必要があります。 現在の環境 アプリケーションの領域が少し特殊で、セッションデータがやたらたまります(ユーザ数何百万のサービスとかそういうのではないです)。 RDBMS MySQL 4.0.22 ストレージエンジン InnoDB レコード数 6千万 テータサ
それ Unicode で
UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。
PHPのSession Fixation問題
(Last Updated On: 2006年10月24日)PHPのセッション管理はセッションの固定化（Session Fixation）に脆弱であることは広く知れらていると思っていました。先日、php-users(ja)のMLに「Hardened PHPプロジェクトのStefanさんのパッチにSQLite Sessionモジュール用のセッションセーブハンドラパッチを追加したパッチを公開しました」と投稿しました。しかし、ダウンロード数等から推測するとセッションの固定化のリスクが正しく認識されていないのではないかと思えます。 セッション固定化のリスクを分かりやすく説明するには具体的な攻撃のシナリオを紹介した方がわかり易いのでいくつか説明します。以下の説明はデフォルト状態のPHPインストールでSession Fixation対策を行っていないのPHPアプリケーションに対して可能な攻撃の一例です
［柔軟すぎる］IEのCSS解釈で起こるXSS
［柔軟すぎる］IEのCSS解釈で起こるXSS：教科書に載らないWebアプリケーションセキュリティ（3）（1/3 ページ） XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます （編集部） なぜか奥深いIEのXSSの話 皆さんこんにちは、はせがわようすけです。 第1回「［これはひどい］IEの引用符の解釈」と第2回「［無視できない］IEのContent-Type無視」でInternet Explorer(IE)の独自の機能がクロスサイトスクリプティング（XSS：cross-site scripting）を引き起こす可能性があるということについて説明してきました。 第3回でも引き続き、IE特有の機能がXSSを引き起こす例ということで、
PHP:既知のセキュリティ脆弱性 – Session Adoption
(Last Updated On: 2018年8月13日)追記：より新しい情報については間違いだらけのHTTPセッション管理とその対策をどうぞ。 PHPには広く知られているにも関わらず放置されている既知のセキュリティ脆弱性が幾つかあります。その一つがセッションモジュールのセッションアダプション(Session Adoption)脆弱性です。この脆弱性は現在広く利用されているWebアプリケーションの安全性に、非常に大きな影響を与える脆弱性です。 セッションアダプション脆弱性とはセッション固定化攻撃を可能とする脆弱性の一種です。セッションアダプションに脆弱なセッション管理システムは、ユーザ(ブラウザ)が送信してきた未初期化のセッションIDを受け入れ、セッションを初期化してしまいます。PHPに限らず、RailsやJavaのフレームワーク等、多くのWebフレームワークに発見されている脆弱性です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
主要ブラウザすべてに影響する「クリックジャッキング」攻撃とは