「わざと脆弱性を持たせたWebアプリ」で練習を
命名・「やられWebアプリケーション」（仮） 構築したWebアプリケーションがセキュアかどうかを確かめる方法として、疑似的に攻撃を行うことで問題を発見する「脆弱性診断」があります。脆弱性診断は専門業者が実施することがほとんどだと思いますが、あなた自らが脆弱性診断の技術を身につけることで、セキュアWebアプリケーションについての理解が深まるとか、自社内で脆弱性診断ができるようになるといったこともあるかもしれません。 脆弱性診断の技術を身につける過程では、脆弱性を見つける手法を試したり、診断ツールを試したりする必要がありますが、診断といえど攻撃と同様のことを行うので、気軽に実稼働環境で実験するわけにもいきません。ましてや、他人や他社のWebサイトで試すなどはもってのほかです。 そこで、わざと脆弱性を持たせたWebアプリケーションと、それを動作させる環境が必要になります。 このような環境をわざわ
マルウェア「Duqu」は未知の言語で開発された？ | スラド デベロッパー
Internet Watchの記事「国家によるサイバー戦争は新局面に？ メディア報道の動きや謎の言語の発見」に興味深い一文があった。記事内容としては、国家ぐるみでのサイバー攻撃が増えているというものなのだが、Kasperskyが「Duqu」というマルウェアを調査したところ、どのようなプログラミング言語で実装されたのかまったく特定できなかったというのだ。 このほか3月8日には、Stuxnetの亜種と考えられているマルウェア「Duqu」に関し、ロシアのKaspersky Labsが奇妙な知見をもたらした。同社では「数え切れないほどの時間を費やしてもなお、Duquが開発されたプログラミング言語を全く特定できない」とし、世界中の研究者に援助を求め、ブログにその分析内容を公開した。 該当のブログによると、Duquのコードが格納されているDLLにはC++のラインタイムライブラリやSTLの関数が含まれて
PHP: PHPの隠蔽 - Manual
PHPの隠蔽 一般に隠蔽という手段はセキュリティとしては弱いものだと言われています。 しかしこうした手法が望ましい場合もあります。 PHP を隠すための簡単な技法がいくつかあり、 システムの弱点を見つけようとする攻撃を遅延させることができる可能性があります。 php.ini ファイルで expose_php を off と設定すれば、 攻撃者が利用可能な情報を減らすことができます。 他の手段は、ApacheのようなWebサーバーで PHPに異なるファイル形式をパースさせるように設定することです。 これは、.htaccessディレクティブまたは Apacheの設定ファイル自体で指定します。 これにより、紛らわしいファイル拡張子を使用可能です。
PHP と Web アプリケーションのセキュリティについてのメモ
このページについての説明・注意など PHP は、Apache モジュールや、CGI、コマンドラインとして使用できるスクリプト言語です。このページでは、主に PHP における、Web アプリケーションのセキュリティ問題についてまとめています。 Web アプリケーションのセキュリティ問題としては、以下の問題についてよく取り挙げられていると思いますが、これらのセキュリティ問題について調べたことや、これら以外でも、PHP に関連しているセキュリティ問題について知っていることについてメモしておきます。 クロスサイトスクリプティング SQL インジェクション パス・トラバーサル(ディレクトリ・トラバーサル) セッションハイジャック コマンドインジェクション また、PHP マニュアル : セキュリティや、PHP Security Guide (PHP Security Consortium) には、PH
[SQLインジェクション対策]Webアプリケーションとかの入門本みたいのを書く人への心からのお願い。 - ＊「ふっかつのじゅもんがちがいます。」withぬこ
SQLインジェクションについて書くときに以下のメッセージを必ず含めて欲しいです。 単にプリペアドステートメントを使え 絶対に文字列結合でSQLを構築しようとしてはいけない IPAの「安全なSQLの呼び出し方」を読むこと なんでこんなことを書くかというと、同僚が献本されてた「プロになるためのWeb技術入門」なる本のSQLインジェクションの項で、SQLインジェクションの対策として以下のように書いてあったからです*1。 a) 値をバリデーションする b) プリペアドステートメントを使う ダメです。間違っています。単に間違っているだけでなく救いがたく間違っています。正しいSQLインジェクション対策はこう書くべきです。 単にプリペアドステートメントを使え 文字列結合でSQLを構築するな イケてない本を書く人はなんで値のバリデーションをプリペアドステートメントよりも先に書くんですか？値のバリデーション
![[SQLインジェクション対策]Webアプリケーションとかの入門本みたいのを書く人への心からのお願い。 - ＊「ふっかつのじゅもんがちがいます。」withぬこ](https://cdn-ak-scissors.b.st-hatena.com/image/square/abd76f3bb0ec0750428a791cbfbf7959c317f97d/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127052840568%2F17680117127052842215%2F1555633900)
『よくわかるPHPの教科書』のSQLインジェクション脆弱性 - ockeghem's blog
このエントリでは、数値型の列に対するSQLインジェクションについて説明します。 以前のエントリで、たにぐちまことさんの書かれた『よくわかるPHPの教科書』の脆弱性について指摘しました。その際に、『私が見た範囲ではSQLインジェクション脆弱性はありませんでした』と書きましたが、その後PHPカンファレンス2011の講演準備をしている際に、同書を見ていてSQLインジェクション脆弱性があることに気がつきました。 脆弱性の説明 問題の箇所は同書P272のdelete.phpです。要点のみを示します。 $id = $_REQUEST['id']; // $id : 投稿ID $sql = sprintf('SELECT * FROM posts WHERE id=%d', mysql_real_escape_string($id) $record = mysql_query($sql) or die(
もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog
たにぐちまことさんの書かれた『よくわかるPHPの教科書（以下、「よくわかる」）』を購入してパラパラと見ていたら、セキュリティ上の問題がかなりあることに気がつきました。そこで、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）」の章・節毎に照らし合わせて、「よくわかる」の脆弱性について報告します。主に、徳丸本の4章と5章を参照します。 4.2 入力処理とセキュリティ 「よくわかる」のサンプルや解説では、入力値検証はほとんどしていません。しかし、入力値検証をしていないからといって即脆弱かというとそうではありません。徳丸本でも強調しているように、入力値検証はアプリケーション要件（仕様）に沿っていることを確認するもので、セキュリティ対策が目的ではないからです。 「よくわかる」の中で、私が見た範囲で唯一の入力値検証は、郵便番号のチェックをするものです。以下に引用します（「よくわ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
