第40回 MOPS：安全性の高いパスワードハッシュ作成ツール - phpass | gihyo.jp
第32回 PHPセキュリティ月間（Month of PHP Sercurity）で「PHPセキュリティ月間」（MOPS - Month of PHP Security）について簡単に紹介しました。 今回はパスワードを安全に保存するツールの紹介です。今まで数回に渡ってMOPSの成果の一部を紹介してきましたが、今回で最後です。 MOPS Submission 10: How to manage a PHP application’s users and passwords http://www.php-security.org/2010/05/26/mops-submission-10-how-to-manage-a-php-applications-users-and-passwords/index.html この論文は1位を取得した論文です。Drupal 7でこのライブラリが利用されてい
文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2010年9月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPカンファレンス2010にて「文字コードに起因する脆弱性とその対策」というタイトルで喋らせていただきました。プレゼンテーション資料をPDF形式とslideshare.netで公開しています。 文字コードのセキュリティというと、ややこしいイメージが強くて、スピーカーの前夜祭でも「聴衆の半分は置いてきぼりになるかもね」みたいな話をしていたのですが、意外にも「分かりやすかった」等の好意的な反応をtwitter等でいただき、驚くと共に喜んでいます。土曜にPHPカンファレンスに来られるような方は意識が高いというの
ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2010年7月1日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPのデータベース・アクセス・ライブラリPDOは、DB接続時の文字エンコーディング指定ができないため、文字エンコーディングの選択によっては、プレースホルダを使っていてもSQLインジェクション脆弱性が発生します。 追記(2011/06/19) ここに来て急にブクマが追加されはじめていますが、このエントリを書いてから状況が改善しています。PHP5.3.6(2011/03/17)にて、PDOでもデータベース接続の文字エンコーディングを指定できるようになりました。この版で、UNIX版のPHPでは解決しましたが、Win
SET NAMESは禁止
(Last Updated On: 2018年8月13日)MySQLには文字エンコーディングを変更する「SET NAMES」SQL文が用意されています。（PostgreSQLも同様のSQL文、SET CLIENT_ENCODINGがあります）この機能はSQLコンソールからは使ってよい機能ですが、アプリケーションからは使ってはならない機能です。SQLインジェクションに脆弱になる場合があります。 Ruby on Railsの本を読んでいて、ActiveRecordを説明している部分にMySQLの文字エンコーディングを変更する場合の例としてSET NAMESが利用されていました。アプリケーションからはSET NAMESは使ってはならない事を周知させるのは結構時間が必要かなと思いました。 PHPも5.2の途中からMySQLモジュールにlibmysqlの文字エンコーディング設定APIのラッパー関数が
ホワイトリストと出力
(Last Updated On: 2018年6月12日)先週末、まっちゃ445というセキュリティ勉強会にお呼び頂きました。未修正のPHP4/5の脆弱性やパネルディスカッションのパネラーとして話をさせて頂きました。関係者の皆様、いろいろ参考になりました。ありがとうございました。 この勉強会の主題の一つがWeb Application Firewall(WAF)でした。パネルディスカッションのテーマもWAFでした。進行役にはサイバー大学の園田さん、パネラーにはサーボーズラボの竹迫さん、HASHコンサルティングの徳丸さん、そして私の4人でパネルディスカッションを行いました。 3人ともWAFの効用や限界に意見の相違はなかったのですが、私と徳丸さんにはシステム開発に於けるブラックリストとホワイトリストの使い方には意見の相違があったと思います。うまく議論をまとめられなかったのでブログに書きます。 追
乱数生成器の取扱い – PHPとPython
(Last Updated On: 2008年9月25日)Stefan Esser氏のブログでmt_srandとそれほどランダムでない乱数（mt_srand and not so random numbers)というエントリが8/17に掲載されています。気になっていたのでPythonの実装も調べてみました。 乱数生成器は擬似乱数生成器 PHPの乱数生成器にはrandとmt_randの2種類がありますが、randはlibcのラッパー関数でmt_randはMersenne Twisterアルゴリズムを利用した乱数生成器です。乱数生成器といってもどちらも擬似乱数生成器なのでそれぞれ、srandとmt_srandで与えたシード同じであればその後に生成される乱数（擬似乱数）は同じになります。これはコンピュータサイエンス系の学科を専攻していれば常識ですが、ご存知でない方も少なくないと思います。 シード
PukiWiki 【FrontPage】
なんだかやけに長い説明ばかり検索に引っかかったので書きました。 Linuxのローカル環境でDockerコンテナ内のXアプリ（GUIアプリ）を利用するには $ xhost localhost + を実行した後に $ docker run --rm --net host -e "DISPLAY" container_image_name x_app_binary_path とすれば良いです。 もっと読む SSHなどよく知られたサービスポートで何も対策せずにいると数えきらないくらいの攻撃リクエストが来ます。不必要なログを増やしてリソースを無駄にし、もし不用意なユーザーやシステムがあると攻撃に成功する場合もあります。 SshguardはC作られており、flex/bisonのパーサールールを足せば拡張できますがカスタム版をメンテナンスするのも面倒です。必要なルールを足してプルリクエストを送ってもマー
PHP と Web アプリケーションのセキュリティについてのメモ
このページについての説明・注意など PHP は、Apache モジュールや、CGI、コマンドラインとして使用できるスクリプト言語です。このページでは、主に PHP における、Web アプリケーションのセキュリティ問題についてまとめています。 Web アプリケーションのセキュリティ問題としては、以下の問題についてよく取り挙げられていると思いますが、これらのセキュリティ問題について調べたことや、これら以外でも、PHP に関連しているセキュリティ問題について知っていることについてメモしておきます。 クロスサイトスクリプティング SQL インジェクション パス・トラバーサル(ディレクトリ・トラバーサル) セッションハイジャック コマンドインジェクション また、PHP マニュアル : セキュリティや、PHP Security Guide (PHP Security Consortium) には、PH
誤解を招く記事 – LAMPセキュリティを強化する4つの方法
(Last Updated On: 2014年12月5日)LAMPセキュリティを強化する4つの方法 http://enterprisezine.jp/article/detail/311 書いてある情報は有用な事も記載されていますが、偏狭な視点からの記述により誤解を招く記事になっていると考えられます。著者はセキュリティの専門家ではないようなので仕方ないかも知れませんが、間違った認識は有害です。 # 原本は読んでいません。もしかすると日本語訳にも問題があるのかも知れません。 実行できる最も重要な対策は、PHPを使わないことです。腐った果物を導入する前に、以下に目を通してください。 後にPerl/Ruby/Pythonの方がかなり安全である旨の記述があります。メモリ管理が必要ない同じスクリプティング言語のレベルで「Perl/Ruby/Pythonを使えばセキュアなアプリケーションができる」と考
GoogleのPython採用と脆弱性情報の関係
(Last Updated On: 2008年4月23日)GoogleがカスタムアプリケーションのホスティングにPythonを採用しました。これにより多くのセキュリティ研究者の研究対象がPythonに向けられ、PHPで報告されていたような問題がセキュリティ脆弱性して多数レポートされるようになるのではないか、と予想していました。 さっそくセキュリティ脆弱性が多く発見されるライブラリの一つであるzlibライブラリにお馴染みの脆弱性が報告されています。 CVE-2008-1721 Integer signedness error in the zlib extension module in Python 2.5.2 and earlier allows remote attackers to execute arbitrary code via a negative signed intege
クエリ文字列のセッションIDはクッキーには出力されない
セッション固定化（Session fixation）を調べている時に気づいたのですが、PHPではクエリ文字列内のセッションIDはクッキーとしては出力されないんですね。 良くセッション固定化で例に挙げられるが下のような例です。 攻撃者がセッションID付きURL[http://example.com/?PHPSESSID=abcd]をユーザAに踏ませる ユーザAのセッションが[セッションID=abcd]で生成される。 ユーザAがログインする。 攻撃者が[セッションID=abcd]でアクセスするとユーザAがログイン済みの状態になっており、セッションを乗っ取る事ができる。 これ自体はもちろんそうなのですが、PHPではクエリ文字列に含まれるセッションIDでセッションは生成されますが、クッキーにそのセッションIDは出力されません。（PHP5.2.1のext/session/session.cを見るとそ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Blogger
SElinux and FC5 - Cacti