ここのところ、いくつかのSQL Injectionツールについて調べていました。今日はその結果を日記に書いてみようと思います。 はじめに SQL Injectionツールとは SQL Injection脆弱性の発見と、発見した脆弱性を突いてのDB内情報の取得を行なうためのツールです。 ただし、多くのツールでは「脆弱性の発見」はおまけで、後者のDB内情報の取得に主眼を置いています。一般的には、汎用のWeb脆弱性スキャナなどで脆弱性を見つけて、その脆弱性に対してこの日記に書いているようなツールを使って情報を取得するという使い方をすることが多いでしょう。 SQL Injectionツールは、いわゆるHackingツールです。脆弱性検査を行なう者か、さもなければCrackingを行なう犯罪者が使うくらいで、一般のWeb開発者やユーザの人が使う必要に迫られることは無いでしょう。 ツールの使用に際して
今更ながらですが、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（
teracc’s blog
表題のとおりですが、 # PHP7.4.3（Ubuntu 20.04）にxdebugをインストール apt install php-xdebug phpenmod xdebug systemctl restart apache2 # xdebugを無効にする phpdismod xdebug systemctl restart apache2 ApacheでPHPのページにアクセスするとsegmentation faultになる。 [Thu Dec 16 19:32:08.276046 2021] [core:notice] [pid 421823] AH00051: child pid 421937 exit signal Segmentation fault (11), possible coredump in /etc/apache2CLIも同じで、gdbで見ると以下のような感じです
まとめると以下のようになると思います。 Oracle % _ ％(全角）＿(全角) DB2 % _ ％(全角）＿(全角) MS SQL Server % _ [ MySQL % _ PostgreSQL % _ 注意点は以下のとおり。 DB2、Oracleは、「％」「＿」（全角）もワイルドカードとして解釈する SQL Serverは、[a-z]のような正規表現的な記述を解釈する 当然、ワイルドカード的な機能を持たせたい「%」や「_」等はエスケープしない 全データベース共通の話として、エスケープ文字自体もエスケープする必要がある（MySQL、Postgresでは「\」がデフォルトのエスケープ文字） likeのエスケープをした後に、Prepared Statementで値をSQLにバインドする （関連）2008-07-10 - T.Teradaの日記
セッションIDと認証チケット - teracc’s blog
以前の日記で、ASP.NETのセッション固定対策について書きました。 その結論をまとめると、 ASP.NETにはセッションIDを変更するまともな方法が存在しない。 そのため、ASP.NETではフォーム認証機構（FormsAuthentication）を使ってログイン状態管理を行うべき。 FormsAuthenticationは、通常のセッションID（ASP.NET_SessionId）とは別の認証チケット（Cookie）をログイン成功時に発行し、この認証チケットによってログイン後のユーザの識別を行う仕組み。 ということになります。 ASP.NETのサイトに限らず、セッション（PG言語やフレームワークに組み込みのセッション機構）と、認証チケットの両方を使用しているサイトはたまに見られます*1 特にポータルサイトのような大規模なサイトは、ログインをつかさどるシステムと、会員向けのブログや日記、
属性値のXXE攻撃 - teracc’s blog
以前、属性値でのXXE（Xml eXternal Entity）攻撃を試したのですが、やり方がよく判りませんでした。 最近また試してみて、属性値での攻撃方法が判ったので日記に書いてみます。 Servletプログラム 以下のようなJava Servletプログラムをサーバに置きます。 import java.io.*; import javax.servlet.*; import javax.servlet.http.*; import org.w3c.dom.*; import org.apache.xerces.parsers.*; import org.xml.sax.*; public class AttrTest1 extends HttpServlet { public void service(HttpServletRequest request, HttpServletRes
携帯電話のリファラー（２） - 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
SHA1でハッシュ化したパスワードは危険になった - yohgaki's blog を読みました。その記事に関連したことを書きます。 ハッシュアルゴリズムの切替え 記事を読んで思い出したのは、既にパスワードをハッシュ化して保存していて、そのアルゴリズムが脆弱になった場合に、いかにアルゴリズムを切替えるかという問題です。 ハッシュデータは元に戻せないため、アルゴリズムを切替えるのも難しいのです。 パスワードはどうやって持つ？ - がるの健忘録 パスワード暗号処理変更用 大雑把草案 - がるの健忘録 上記の日記で、この問題を扱っています。その日記の中では、 ユーザがログイン成功した際に、システム側でパスワードが判る。 その際に、DB保存データを新アルゴリズムの形式にする。 という方式が提案されています。この方式では、システム更新後に、ログインしたユーザから順次新しいアルゴリズムになります。ログ
Piece FrameworkはPHPのフレームワークです。 セキュリティに強い、そして日本人が開発している、というのが特徴のようです。 【PHPウォッチ】第34回 セキュアでロバストなPHPフレームワーク「Piece Framework」：ITPro Piece Framework - A stateful and secure web application framework for PHP 早速触ってみました。 概要 以下の3つの要素から構成されます。 Piece_Unity: 基本 Piece_Right: Validation Piece_Flow: フロー制御 一番の売りは、フロー制御のようです。これを使うと、Webアプリ開発者が意識せずとも、CSRF脆弱性を持たないフォームを作れます。 デモサイトでフロー制御を体験 デモサイトが用意されています。 Piece Framewo
DB2の文字列→数値変換 - teracc’s blog
だいぶ前に徳丸さんが、文字列から数値への暗黙の型変換についてまとめています。 数値リテラルをシングルクォートで囲むことの是非 - ockeghem's blog 徳丸さんの日記には、Oracle, MS SQL Server, MySQL, PostgreSQLの4つのDBMSを対象に、暗黙の型変換が起こるかを実際に調べた結果が書かれています。 私が思うところ、割とメジャーなDBMSで網羅されていないのはDB2です。 というわけで、今日の日記ではDB2の挙動について書きます。 下は、DB2 V9.5での動作です。 [db2inst1@localhost ~]$ db2 "SELECT * FROM staff WHERE id=10" ID NAME DEPT JOB YEARS SALARY COMM ------ --------- ------ ----- ------ ------
ページの閲覧履歴 - teracc’s blog
有害なエントリーを書いてしまい申し訳ありませんでした | 松下健次郎のブログ この問題（CSS History Hack）への対策として作られたFirefoxのAddonがあります。 https://addons.mozilla.org/ja/firefox/addon/1502 https://addons.mozilla.org/ja/firefox/addon/1474 SafeHistoryは当時（2006年ごろ）と今インストールして使ってみましたが、問題なく動きました（余りちゃんと調べてませんが）。SafeCacheの方は使ったことはありません。 なお、SafeCacheは正確には別の種類の攻撃（HistoryではなくCacheに対する攻撃）に対処するものです。 ＜参考＞ History関連：147777 - :visited support allows queries int
teracc’s blog
表題のとおりですが、 # PHP7.4.3（Ubuntu 20.04）にxdebugをインストール apt install php-xdebug phpenmod xdebug systemctl restart apache2 # xdebugを無効にする phpdismod xdebug systemctl restart apache2 ApacheでPHPのページにアクセスするとsegmentation faultになる。 [Thu Dec 16 19:32:08.276046 2021] [core:notice] [pid 421823] AH00051: child pid 421937 exit signal Segmentation fault (11), possible coredump in /etc/apache2CLIも同じで、gdbで見ると以下のような感じです
loopback - teracc’s blog
http://127.0.0.1/ と同じ意味となりうるURL。 ブラウザでアクセスするというよりは、HTTPクライアントとして機能するWebアプリに食わせます。 (一部のサーバ環境でしか動かないものもあります。) http://127.0.0.1/ 普通の表記 http://127.0.1/ 2,3番目のバイトをまとめる http://127.1/ 2,3,4番目のバイトをまとめる http://127.1.2.3/ 2,3,4番目のバイトは何でもいい http://127.66051/ 上の2,3,4番目のバイトをまとめる http://017700000001/ 全バイトをまとめて8進数で http://0017700000001/ 0をもうひとつ http://2130706433/ 全バイトをまとめて10進数で http://02130706433/ 0を頭につけても10進数と解
CookieのPath - teracc’s blog
遅ればせながら、高木さんの日記を見ました。 高木浩光＠自宅の日記 - 共用SSLサーバの危険性が理解されていない CookieのPath指定がセキュリティ上意味を持たない件について書かれています。 日記に書かれたIFRAMEを使う方法で既に「詰み」なのですが、もうちょっと別の方法（JavaScriptを使わない方法）について書きます。 URLを細工する 被害者の「http://example.jp/aaa/」のCookieを「http://example.jp/bbb/」から取得することを考えます。攻撃者は「/bbb/foo.cgi」というCGIを置いて、被害者に以下のようなURLを踏ませます。 URL1: http://example.jp/aaa/%2E./bbb/foo.cgi URL2: http://example.jp/aaa/..%2Fbbb/foo.cgi ※ %2Eは「.
以前の日記では、外部からのXMLをサーバサイドでParseするアプリへの攻撃の概要について書きました。 今日の日記では、何点か補足する事項について書きます。 ファイルの内容を盗み出す他の方法 前の日記の中で、サーバ上のファイルの内容を外部から盗み出すにはいくつかの条件があると書きました。 その条件のひとつに「コーディングのスタイル」がある、具体的には「textContent」で要素の内容を取得するアプリ（下のPHPコードではAのスタイルのアプリ）でのみ、サーバ上のファイルの内容を盗まれる可能性がある、と書きました。 <?php ... $elm = $doc->getElementsByTagName('test')->item(0); // A: 外部実体参照が展開される $var = $elm->textContent; // B: 外部実体参照は展開されない $var = $elm-
OpenIDについて調べた - teracc’s blog
最近やっと、OpenIDというものの存在を知りました（遅い！）。 自分のブログURLをIDで使える!―OpenID.ne.jp(オープンアイディー） ちょっと調べてみました。 概要 いわゆるSSO（シングルサインオン）サービスです。 単一のID/パスワードで、複数のWebサイト（Consumerと呼ぶ）にログインできるようにする。 パスワード情報は認証サーバ（IdPと呼ぶ）で一元管理する。 ユニークなのは、自分のHPのURLをIDに使うところです。 大まかな仕組みは以下のようなものです*1。 ユーザは、事前にIdPにパスワードなどを登録しておく。 自分のHPのLINKタグに自分の使うIdPを記述する。 ユーザがConsumerに自分のID（HPのURL）を提示すると、ConsumerはHPのLINKタグを読んで、そのIdPのURLにリダイレクトする。 ユーザはIdPの画面でパスワード認証を
ログイン成功時のリダイレクト先 - teracc’s blog
高木浩光＠自宅の日記 - ログイン成功時のリダイレクト先として任意サイトの指定が可能であってはいけない 簡単な対処方法は、Yahooがやっているように、ログイン成功時に「backurl」のドメインなどをチェックをして、「自サイト外」ならばリダイレクトせずにエラーにする方法なんでしょう。 ですが、「自サイト内」に任意サイトに飛べるリダイレクタを抱えていると、 ログイン成功 → 自サイト内のリダイレクタへ → 外部のフィッシングサイトへ のように、多段階のジャンプでフィッシングサイトへ飛ばされる恐れがありますね。 現状、大規模なサイトの多くが「backurl」的な機能を持っており、また自サイト内に任意サイトに飛べるリダイレクタをいくつも抱えているのではないかと思います。 この種の脆弱性届出が受理され、修正された（少なくとも「はてな」などいくつかのサイトでは）ことの影響は、思ったより大きいかもし
AntiSamyをためす - teracc’s blog
OWASPがAntiSamyというオープンソースのソフトウェアをリリースしました。 Category:OWASP AntiSamy Project - OWASP ツールの名前は、有名なMySpaceのJavaScript Wormからきています（多分）。 HTML断片から、JavaScript要素を除去するためのソフトで、現行版はJavaで作られています。プロジェクトのホームページによると、将来的にPHPや.NET環境にも移植される予定とのことです。 V1.0をダウンロードしてちょこっと触ってみました。 以下、メモ＆感想です。 ParserとしてNekoHTMLを使用している。 XMLのポリシーファイルと、ポリシーファイルに基づいてHTMLを処理するエンジンで構成されている。 ポリシーファイルには、許可するHTMLタグ・属性名・属性値、CSSプロパティ名・値などのパターンを、正規表現をつ
pg_sleepを使った検査 - teracc’s blog
徳丸さんの日記（pg_sleepをSQLインジェクション検査に応用する - ockeghem's blog）を読みました。 こういう検査のマニアックな話は大好きです。 このあたりのシグネチャは、私も自作ツール（参考）の検討をしていた際に相当いろいろ悩んで調べましたので、今回はUPDATE文のSET句などにも適用できるような改善の提案をしたいと思います（おろらく既に徳丸さんの頭にあるものだとは思いますが）。 徳丸さんの日記の検査パターンは、以下の値を挿入するものでした。 ' and cast( (select pg_sleep(3)) as varchar) = 'これを少し変えて、以下のようにします。 ＜文字列型＞ 【元の値】'||(select pg_sleep(3))||'数値型であれば、以下のようにします。 ＜数値型＞ 【元の値】-cast(chr(48)||(select pg_s
大垣さんの連載がはじまったようです。 なぜPHPアプリにセキュリティホールが多いのか？ 連載の一回目は、以下のような内容でした。 CVEに登録される脆弱性全体のうち、PHP AP関連は半数弱を占める。 PHP APの脆弱性の約4割は、Remote File Inclusionという深刻なもの。ただし、register_globals設定がOnの環境でのみ脆弱なものが多い。 つまり、register_globalsが、PHP APの脆弱性件数を底上げしている面がある。 今日の日記では、その記事を読んで、少し調べたこと、思ったことなどを書きます。 Remote File Inclusionについて register_globalsがOnだからといって、Remote File Inclusionが可能になるなんて、一体どんなコード書いてるのよ？ と思って、CVEで挙げられていたいくつかのAPを調
今日の日記では、以下のようなPHPコードへの攻撃について書きます。 <?php include "/path/to/". $_GET['file']; セキュリティ本でよく紹介されるのは、file=../../etc/passwd のようなクエリストリングを与える攻撃です（合せて、末尾にNUL文字を付ける攻撃方法もよく紹介されます）。 ただし、当然のことながら、/etc/passwd の中身を外部の攻撃者が制御することはできないため、攻撃者が任意のコマンドを実行することはできません。 /etc/passwd だけでなく、多くのサーバ上のファイルは外部から内容を制御できません。しかし、いくつかのファイルは、外部から制御することができます。攻撃者は、このようなファイルにPHPコマンドを埋め込み、それを include する可能性があります。 外部から制御可能なファイル 外部から内容を制御できる
検査ツール作成の一環として、SQL Injection脆弱性を利用してデータを抜き出すツールを作成しました。 使い方 この手のツールを使ったことがある人は、見れば何となく分かると思いますが、簡単に説明します。 まずは、検査対象のリクエストとパラメータを指定します。指定できるパラメータは、GET/POSTパラメータ、Cookie、HTTPヘッダ、URLパスです。 次に、DBから抜き出したいデータを指定します。デフォルトではDBMSのバージョンを抜き出します。それ以外のSQL文の実行結果も抜き出し可能ですが、現時点では、文字列型のスカラー値を返すSQL文のみが指定可能です。逆に言うと、複数行もしくは複数列を返すSQL文は指定できませんし、DBMSによっては数値型のスカラー値を返すSQL文も指定できません。*1 その次に、SQLエラーの判別方法を指定します。データを抜き出すためには、パラメータを
CSRFとReferer改竄 - teracc’s blog
seasurfersというMLに参加している。このMLの名称（seasurfers）は、CSRF（Cross Site Request Forgery）をひねった？もののようで、CSRFをはじめとしたWeb APセキュリティが主な話題のようだ。 ここで最近取り上げられていたのは、RefererでCSRFを防止する対策の問題だ。この対策は、攻撃者が自身のRefererを制御（改竄）するのはたやすいが、第三者のRefererを制御するのは不可能であることを利用したもの。Refererチェックは技術的に簡単にできるため、RefererでCSRF対策を行なっているサイトも多いかもしれない。 MLで話題になっていたのは、Flashの欠陥（bugtraqに7月に投稿された記事、交差点の猫 - リファラーを 偽装するのよ Flashで）を利用すると、攻撃者が被害者を任意のサイトにアクセスさせ、その際のR
http://www.owasp.org/index.php/OWASP_Testing_Project ざっと中身を見てみました。270ページもあるので、読み終わる頃には目がしょぼしょぼになります。 SDLC全体でセキュリティ対策をする・・・というように書かれていますが、内容的にはPenetration Testの方法（というよりも攻撃方法かな）がメインです。 あと記述レベルにばらつきがあるなぁとも思いました。 とりあえず、メモを貼り付けておきます。斜め読みだったこともあり、間違っているところもあるかもしれません。 １．Frontispiece ・本文書について（略） ２．Introduction ・SDLC全体で標準・ポリシー・ガイドラインを作ってセキュリティを高める。 ・一般的には、技術的な欠陥やPenetrationテストに偏っていることが多い。 ・以下をバランスよく。 MANUA
WASCのWeb Security MLの少し前の投稿より。 Tactical Web Application Security: Mass SQL Injection Attacks Now Targeting PHP Sites 自動化されたSQL Injection攻撃が、現在はPHPサイトをターゲットにしているとの内容の記事です。 確かに、SQL Injectionによって埋め込まれるJSファイルのURLをキーワードにしてGoogle検索すると、拡張子がphpのページもヒットします。 "1000mg.cn/csrss/w.js" - Google Search 個人的に一番気がかりなのは、これまで狙われていたSQL Server以外のデータベースが新たに攻撃対象になっているのか（あるいはそうではないのか）ということです。 そこにも関わりそうな話なので、可能な範囲で調べてみました。
Anti-XSSライブラリのV3.1から、GetSafeHtml()やGetSafeHtmlFragment()といったスタティックメソッドが用意されました。これらのメソッドは、入力として与えられたHTMLやHTML断片から、JavaScriptを除去するためのものです。 （参考）HTML Sanitization in Anti-XSS Library – Security Tools 今回は、HTML断片を処理するGetSafeHtmlFragmentメソッドを試してみました。 挙動を見る限り、タグ/属性に加えてCSSもホワイトリストベースで処理されます。かなり出来がよいライブラリです。IE8のtoStaticHTML関数がいまいちだったので（参考）、余り期待していませんでしたが、少なくともtoStaticHTMLよりもはるかによいです。 ただ現時点で実際のサイトに適用するうえでは問題
Yahooのログインシール - teracc’s blog
Yahoo! Japanが新たなフィッシング対策を導入したそうです（産総研との共同実験のとは別物です）。 ヤフーは26日、フィッシング詐欺対策として、Yahoo! JAPAN IDのログイン画面に、ユーザーが設定した写真や文字列を表示する「ログインシール」機能を追加した。ログイン時にこれがきちんと表示されるているかどうか確認することで、偽のログイン画面に気付きやすくなるとしている。 ヤフー、フィッシング対策として“マイログイン画面”の設定機能 シール画像を登録した際に、永続的なCookieをブラウザにセットする仕組みです。ログイン画面にアクセスすると、Cookieがサーバに送信され、サーバは対応する画像をログインフォームの隅に付けた画面をレスポンスします*1。 通常、フィッシングを避けるためにユーザがすべきことは、①アドレスバーのURL（ドメイン）を目視確認、②SSL証明書のエラーが出ない
HTML Purifierの4.1.1がリリースされました。今回のリリースには1件のSecurity Fixが含まれています。今日はその内容について少し書きます。 IEのCSSのurl()の扱い 以下のようなstyle属性があったとき、ブラウザはどのように解釈するでしょうか？ <span style="background: url('http://host/aaa\'\);color:red;')">111</span> Firefox、Opera、Safariでは、「http://host/aaa');color:red;」というURIをもつbackgroundプロパティと解釈します。したがってcolorプロパティが有効になることはありません。これはCSSの仕様から見ても至極妥当な挙動です。 ところがIEだけが違う解釈をします。IEで上記のHTMLを表示させると、backgroundプ
ディレクトリトラバーサルは、比較的発見が容易な脆弱性です。 検査文字列を検討する際にポイントとなるのは、どのファイルを見に行くか、NULL文字を入れるか、くらいではないかと思います。 UNIX系OS用のシグネチャ UNIX用のシグネチャは1パターンしか用意しませんでした。 /../../..（省略）/etc/hosts[0x00]【元の値】ファイルは/etc/hostsとしました。 /etc/hostsは、Linux、Solaris、FreeBSD、AIX、HP-UXなど主要なUNIX OSに存在します（商用UNIXについては手元に環境が無いので、ネット上の情報からそう判断してます）。 検査文字列の先頭を「../」にするか、あるいは「/../」にするかも一つのポイントです。【元の値】が「/foo/bar.txt」のような値であるならば、検査文字列の先頭が「../」だとうまくいかない可能性が
like演算子のエスケープ - teracc’s blog
SQLのlike演算子では、ワイルドカードとして解釈させたくない「%」や「_」をエスケープする必要があります。 じゃあエスケープ文字として何を使えばいいんだろうか？という話になりますが、それに関して昔自分がやった失敗を思い出しました。 自分がやった失敗というのは、エスケープ文字として「%」を使おうとしたことです。SQL文で「'」を「'」でエスケープするのと同じようにすればよいだろうと考えた訳です。 例えば「20%以内」を含むデータを検索するSQL文を以下のように書きました。 ... WHERE foobar LIKE '%20%%以内%' ESCAPE '%';データベースの種類にもよりますが、これはこれで期待したとおりに動きます。 しかし、このSQL文を見てふと思ったのが、「%」を含むデータを検索したい場合にどうなるんだろうか？ということです。 ためしに書いてみると、こんな感じになるはず
Jiktoのソース - teracc’s blog
Jeremiah Grossman氏のブログなどに書かれていますが、非公開としていたJiktoのソースコードが流出したそうです。 あわせて、先月のShmooConでのプレゼン資料が公開されています（概要だけならば、この資料の方が理解しやすいです）。 ソースコードとプレゼン資料を見ましたが、どうも私が想像していたのとは違いました。どちらかというと、JiktoはカスタムWebAP用の脆弱性スキャナに近いもののようです（Niktoとは毛色が違います）。 Jiktoは他のカスタムWebAP用の脆弱性スキャナと同じように、リンクを辿ってページを探索し、脆弱性の有無を調べます（ページはXHRで取得する）。現状では、検査対象となる脆弱性は、XSSとバックアップファイルの存在のみで、しかも非常にシンプルな攻撃パターンしか備えていません。 ポイントは、プロキシサイトや、同等の動きをするGoogle Tran
「こんにちは」は昔から「こんにちは」でしたが、「こんばんは」は昭和61年7月1日に「現代語仮名遣い」が内閣告示されてから定着したものであり、それ以前は「こんばん わ」にも市民権がありました。 ８０年代前半まで、挨拶言葉は「こんにち は」&「こんばん わ」が主流であり、全国区かわかりませんが、学校でもこの通りに教えていました。 （略） 「こんばん わ」が正しい、と思っている人が年配者になるほど多いのはこのためです。概ね変遷期に小中学生だった１９７０年代生まれくらいが境になっています。 「こんにちわ」撲滅委員会 会員様のご意見（会員番号0693番） だそうです。 「こんばんわ」と「こんにちわ」では、少々事情が違うようです。私は両方一緒くたに、若者を中心とした「誤用」だと思っていました。 昭和61年の内閣告示（現代仮名遣い）により、現代では「は」が標準と言えそうですが、「わ」も多用されています。
おかしなHTMLエスケープ - teracc’s blog
PHPでのプログラミングを取り上げたサイトで、少々おかしなコードを見つけた。 調べてみると、他にも同じような書き方をしているサイトをいくつか見つけたので、日記のネタにしてみようかと思う。 そのコードは、以下のようなもの（表示の都合で折り返している）。 <a href="foo.php?SESS=<?= htmlspecialchars($sid) ?>">次へ</a> $sidはセッションIDで、これをHTMLエスケープしてアンカーURLの後ろにくっつけている。リンクを辿った際に、セッションIDが次ページに引き継がれるようにするためだ。 ちなみにPHPでは、クライアントが送ってきたセッションID（GET/POST/COOKIE問わず）が、サーバ側で管理しているセッションIDの一覧の中に無い場合、送られてきたセッションIDでセッションを開始するというという動作をする*1。そのため、セッション
Scrawlrを試す - teracc’s blog
http://www.microsoft.com/japan/technet/security/advisory/954462.mspx MSが、SQL Injection対策ツールを3つほど紹介しています。 そのうち、Scrawlrを試してみました。 Technical details for Scrawlr * Identify Verbose SQL Injection vulnerabilities in URL parameters * Can be configured to use a Proxy to access the web site * Will identify the type of SQL server in use * Will extract table names (verbose only) to guarantee no false positive
趣味の検査ツール作成 - teracc’s blog
ここのところ日記も書かずにいましたが、実は自前のWebアプリケーションの検査ツールを作るのに没頭していました。 作ったツールの特徴をいくつか挙げると、 手動検査の補助ツールの位置付け ツール自体がWebアプリ（PHPで8KL以下の分量） 主にインジェクション系の脆弱性を検出する それ自体にはプロキシ機能はない レポート作成用の機能はない のような感じです。 ツール自体は今のところ公開する予定はありませんが、一部のシグネチャについては（私が所属する会社固有のノウハウと思われる部分を除いて）日記に書いていこうと思います。
括弧なしのXSS - teracc’s blog
hoshikuzuさんの日記から。 詰めXSS回答第弐回（分割方式） これ、SCRIPTタグの内側に挿入できるけれども、括弧など殆どの記号がはじかれてしまうアプリがあって、仕事で1回だけ使ったことがあります。 とはいっても、hoshikuzuさんの記事の後半に書いてあるような技を使ったわけではなく、私の場合は単純に「a setter=alert,a=123」みたいのを入れて「詰み」としました。 私がsetterを使う手法を見つけたのはこちらのページです。 http://sla.ckers.org/forum/read.php?2,20954 sla.ckers.orgのXSS Info Forumは、まさにこの手のネタの宝庫です。 ＊＊＊ ところで、setterを使ったのは、以下のような経緯でした。 私・・・XSSを報告 ↓ 開発者・・・なぜか括弧などの記号が使えないように改修 ↓ 私・・
調べものをしている中で、今さらながらSame-Site Cookieの仕様書を斜め読みした。 ググって最初に見つけた仕様の中で、same-siteは下のように定義されていた。 A request is "same-site" if its target's URI's origin's registrable domain is an exact match for the request's initiator's "site for cookies", and "cross-site" otherwise. Same-site Cookies draft-west-first-party-cookies-07 2.1 (April 6, 2016) 対象（target）と始点（initiator）のサイトが一致すればsame-siteということになる。 リダイレクトを挟むとどうなるか
今年もプラチナチケット（$1,895）が無料で購入できる欠陥があったそうです。 Superimposing Nothing Nowhere: Another Free MacWorld Platinum Pass? Yes in 2008! どんな方法で無料で買えたのかと言うと。。。 Apple（もしくはExpo主催者のIDG）は、チケットを無料（もしくは割引）で購入するための「Priority Code」と呼ばれるパスワードみたいなものを、上客の人達に郵送 or Eメールで配った。 Webサイト上の購入ページで、「Priority Code」を入力すると、無料（もしくは割引）で購入できるようになっていた。 ユーザが入力した「Priority Code」が正しいかをJavaScriptで検証できるように、発行した「Priority Code」の全て（1500個ほど）のMD5ハッシュをWeb
価格の改竄などの話 - teracc’s blog
ECサイトにおける価格の改竄の対策として、「購入確定処理で、クライアントからPOSTされてくる商品IDをキーに商品マスタテーブルを検索して、検索した結果の価格で購入処理を行なう」というような趣旨の対策が書いてあるのを見たことがあります。 これは悪意あるユーザによる価格改竄の対策として正しいわけですが、私は別の問題で少々引っかかるものを感じてしまいます。 私が「引っかかるところ」について、以下で少し書いてみます。 運営者による価格変更 購入確定処理の直前には、購入確認画面がユーザに提示されているはずです。 ┏━━━━━━━━━━┓ ┃ ＜購入確認画面＞ ┃ ┃ ┃ ┃ みかん 1個 100円 ┃ ┃ ---------------- ┃ ┃ 合計 100円 ┃ ┃ ┃ ┃上記を購入しますか？┃ ┃ ┃ ┃ [購入確定] [戻る] ┃ ┗━
パスワードのハッシュ化の話 - teracc’s blog
WASCのMLが、非常に盛り上がってました。 The websecurity June 2008 Archive by thread SSL通信でも、ブラウザ上でパスワードをハッシュ化してからサーバに送るべきなんじゃないの？ という話です。SSLプロトコル自体や実装上の欠陥がある場合や、弱い暗号が使われる場合などでは、SSLも完全ではないのだから、多層防御すべき・・・というのがその主張の根拠のようです。 しかし、MLの議論では、この主張に対する否定的な意見が多かったように思います。SSLが安全でない前提に立つと、パスワードをハッシュ化したり、チャレンジ・レスポンス方式にしたとしても、殆ど安全にはならないからです。もしSSLに問題があるならばSSLの問題を直すべきであり、殆ど効果が無いハッシュ方式は「false sense of security」だということでしょう。 ところで、実際にブラ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQL Injectionツール - teracc’s blog
今更ながらmagic_quotes_gpcの欠点 - teracc’s blog
SQLのlike演算子でエスケープが必要な文字 - teracc’s blog
SHA1でハッシュ化したパスワード - teracc’s blog
Piece Frameworkを試した - teracc’s blog
XMLをParseするアプリのセキュリティ（補足編） - teracc’s blog
なぜPHPアプリにセキュリティホールが多いのか？ - teracc’s blog
PHPでのFile Inclusion - teracc’s blog
SQL Injection Toolの作成 - teracc’s blog
OWASP Testing Guide v2 - teracc’s blog
自動化されたSQL Injectionの攻撃対象 - teracc’s blog
Anti-XSS Library v3.1を試す - teracc’s blog
HTML PurifierのSecurity Fix - teracc’s blog
自作検査ツール - ディレクトリトラバーサル編 - teracc’s blog
「こんばんわ」と「こんにちわ」は同列に語れない - teracc’s blog
リダイレクトとSame-Site Cookie - teracc’s blog
Mac World Expoのチケットが無料に - teracc’s blog