メモリのビット反転エラーとセキュリティの話｜Rui Ueyama
ハードウェアのエラーでメモリの内容が化けてしまうことが稀にある。大抵のDRAMエラーはせいぜいプログラムがクラッシュする結果になるだけだが、データ破壊になることもありえるし、悪意のある使い方をすればセキュリティ破りに使うこともできてしまう。ここではメモリエラーとセキュリティの話をしようと思う。 メモリのエラー率は意外なほど高い。データセンターで大規模なマシン群を対象に実際に観測したところ、1年間に1回以上のエラーが発生したDIMMモジュールは全体の8%にのぼったそうだ。DIMM 1枚に数百億個のメモリセルが実装されているといっても、このエラー率はちょっとびっくりするくらい大きな数字ではないだろうか？ サーバでは普通はエラー訂正付きのDIMMを使うので1ビットのエラーは問題にならないが、エラー訂正のないコンシューマ機器ではこれは実際的な問題になりえる。 メモリエラーを利用したセキュリティ破り
「10日でおぼえるPHP入門教室 第4版」はセキュリティ面で高評価
弊社本社の麻布十番移転に伴い、本社近くの麻布図書館を利用しています。麻布図書館は土地柄のイメージにあう瀟洒な建物で、蔵書がない場合は港区の他の図書館から取り寄せ（無料です）ができますので、よく利用しています。今回は、山田祥寛さんの「10日でおぼえるPHP入門教室 第4版 」を借りて読んでみました。一読して、本書がセキュリティにもよく配慮されていることがわかりましたので、以下にご紹介したいと思います。 クロスサイトスクリプティング(XSS) 表示の際にHTMLエスケープするという原則を忠実に守っています。そのため、下記の e() という関数を定義して呼び出しています。 function e($str, $charset = 'UTF-8') { return htmlspecialchars($str, ENT_QUOTES, $charset); } その他にもXSS対策として重要な下記の
SSL通信の根本を揺るがす「SuperFish」問題をどう見るべきか
SSL通信の根本を揺るがす「SuperFish」問題をどう見るべきか：セキュリティクラスター まとめのまとめ 2015年2月版（1/3 ページ） PCにプリインストールされたソフトが通信に割り込み、その内容を全て見ていたかもしれない――2015年2月、レノボの「SuperFish」問題は大きな爪痕を残しました。 連載目次 2月と言えば情報セキュリティ月間改め「サイバーセキュリティ月間」です。脆弱性による大きなインシデントは発生せず、ほっとしていたのもつかの間、レノボのPCにSSL通信を書き換えるアドウエアが、レノボ自身の手によって仕込まれていることが明らかとなり、大きな騒ぎとなりました。 さらに、セキュリティクラスターの風物詩的なものとして長く見守られていたいわゆる「バリデーション論争」がついに終わりを迎えることとなります。 レノボのPCに「SuperFish」の凶悪なアドウエアが仕込まれ
第23回 まだまだ残っているCSRF攻撃 ：なぜPHPアプリにセキュリティホールが多いのか?｜gihyo.jp … 技術評論社
CSRF（Cross Site Request Forgeries）は数年前にその危険性が広く認知された攻撃手法です。Webページを見ただけで、普段自分が利用しているログインが必要なサイトに意図しないリクエストが送信されたりする問題です。 CSRFの動作原理 CSRFは攻撃用の情報を含んだWebページやEメールを利用して攻撃します。被害者が攻撃用のページを表示したり、URLをクリックすると、攻撃対象のWebサイトに利用者が意図していないリクエストを送信します。 図1 CSRF攻撃 CSRFによる不正なリクエストは被害者からリクエストなので、ログインが必要なサイトであっても既にユーザがログイン済みの場合、正規のユーザからのリクエストとして攻撃対象のWebサーバはリクエストを受け付けてしまいます。 ログインが必要ない公開サイトであっても、問い合わせフォームから大量の不正な情報が登録される、など
Secure Sockets Layer - Wikipedia
TLSは特定のアプリケーション層プロトコルに依存しないため、HTTP以外にも多くのプロトコルにおいて採用され、クレジットカード情報や個人情報、その他の機密情報を通信する際の手段として活用されている。 既存のアプリケーション層プロトコルでTLSを利用する場合、大きく2つの適用方式が考えられる。まずひとつは、下位層（通常はTCP）の接続を確立したらすぐにTLSのネゴシエーションを開始し、TLS接続が確立してからアプリケーション層プロトコルの通信を開始する方式である。もうひとつは、まず既存のアプリケーション層プロトコルで通信を開始し、その中でTLSへの切り替えを指示する方式である。切り替えコマンドとしてSTARTTLSが広まっているため、この方式自体をSTARTTLSと呼ぶこともある。 前者はアプリケーション層のプロトコルをまったく変更しなくてすむことが利点である。その反面、平文で接続を開始する
EximのGHOST脆弱性の影響とバリデーションの関係
追記(2015/2/6) 大垣さんから訂正依頼のコメントを頂いておりますので合わせてお読みください。徳丸としては特に訂正の必要は感じませんでしたので、本文はそのままにしています。そう思う理由はコメントとして追記いたしました。 (追記終わり) 大垣さんのブログエントリ「GHOSTを使って攻撃できるケース」を読んだところ、以下のようなことが書いてありました。 1. ユーザー入力のIPアドレス（ネットワーク層のIPアドレスではない）に攻撃用データを送る。 2. バリデーション無しで攻撃用の不正なIPアドレスをgethostbyname()に渡される。 3. ヒープオーバーフローでヒープ領域のメモリ管理用の空きサイズを改竄する。 【中略】 どんなソフトウェアが危ないのか？ ユーザー入力のIPアドレスをバリデーションしないでgethostbyname()を使用している。 インタラクティブな動作を行っ
PHP 5.4 以上でも register_globals を再現するライブラリ MercifulPolluter - Qiita
あらすじ PHP と呼ばれる言語では、かつて register_globals という機能が猛威を奮っていました。簡単に言うと、リクエストパラメータが自動的にグローバル変数にセットされるというものです。 // http://example.com/?foo=123&bar=baz var_dump($_GET['foo'], $_GET['bar']); // string(3) "123" // string(3) "baz" var_dump($foo, $bar); // string(3) "123" // string(3) "baz" この機能が全盛期だった頃、残念ながら私は PHP を書いていませんでしが、おそらくこの機能が ON になっていることで「うわ、何も考えなくても勝手に変数として使える!便利だ!!」みたいな、 よしなにやってくれる という PHP 特有の機能でもダン
第14回 減らないSQLインジェクション脆弱性 | gihyo.jp
SQLインジェクション脆弱性を狙った大規模な攻撃が繰り返し行われ、数万から数十万ページが改竄される事件が何度も発生しています。SQLインジェクションは簡単に対策できる脆弱性ですが、未対策のアプリケーションが多く利用されています。外部からの脆弱性の検出も容易であるため、現在でもWebアプリケーション脆弱性の代表的存在です。 SQLインジェクション脆弱性が無くならない理由には以下のようなものが考えられます。 過去のコードやアプリケーションの再利用 基本的なセキュリティ知識不足 セキュアコーディングプラクティスの未実施 コード監査の不在 SQLインジェクション脆弱性の発見だけを目的にコード監査を行うことはあまりありませんが、SQLインジェクション脆弱性のコード監査は比較的簡単です。MySQLモジュールまたはPostgreSQLモジュールを利用している場合を例に紹介します。 本題に入る前にSQLイ
/etc/hostsに 127.0.0.1 cmertv.com を足した - mizchi's blog
こういうの ゼルダ、Portal、ソニックなど。ゲーム音楽をバンジョーで演奏 ｜ コタク・ジャパン 動画広告、記事読んでる横で15s程度の動画が流れるくらいだったら、そんなロースペックなマシン使ってるわけでもないしどうでもいいんだけど、突然大音量で流されると心の用意出来てないしオフィスいるかもしれないしで、最高にブチ切れそうになる。 止める方法がわからない場合、ブラウザごと落とすことを止むを得ない。 しかもヘッダに近い場所じゃなくて、記事末尾とかにおいてるサイトも多い。cmerが悪質なのは、わかったところで再生を止める方法が提供されてないこと。悪質すぎる。 個人的には積極的に不買運動せざるを得ない。とりあえずこれが原因で kotaku.jp をRSSリーダーから外した。 「テレビCMの再価値化を目指す」――CMer TV 五十嵐社長に聞く | AdverTimes（アドタイ）
第1回 Ajaxとクロスサイトスクリプティング | gihyo.jp
初回はWeb2.0の中核技術ともいえるAjaxを見ていきたいと思います。 Ajaxのセキュリティについて考えていきますが、その前にAjaxについて簡単におさらいしてみましょう。 AjaxとはAsynchronous JavaScript XMLの略であり、一言で言えばJavaScriptとXMLを使って非同期に通信するということです（XML以外の形式が使われることも多くなりました）。通信を非同期にすることで、何か処理をする場合にいちいち待たなくても次の処理に移ることができます。その結果、ユーザを待たせずに多くの処理を行えるようになりました。また、画面全体を再読み込みする必要がなくなったことも、使い勝手の向上した理由です。 Ajaxの動作 それでは簡単なサンプルコードでAjaxの動作を見ていきたいと思います（リスト1）。これらはAjaxの入門サイトや書籍で一番最初に出てくるコードです
なぜPHPアプリにセキュリティホールが多いのか?：第1回 CVEでみるPHPアプリケーションセキュリティ｜gihyo.jp … 技術評論社
PHPアプリケーションの脆弱性は本当に多いのか？ アプリケーションの脆弱性を調べるには、CVEを参照するのが簡単です。 CVEとは、NISTが公開しているソフトウェアの脆弱性データベースです。脆弱性を一意に特定できるIDを付与することを目的としています。Webアプリケーションの脆弱性もCVEに登録されています。CVEに2006/12/31に登録されたアプリケーションの脆弱性の数（同じアプリケーションは除く）は次の通りでした。日によって登録される脆弱性の数は異なります。12月31日は比較的多くの脆弱性が登録されました。 通常どおりPHPアプリケーションの脆弱性が目立ちます。特にこの日は同じアプリケーションで複数の脆弱性が登録されていたものがいくつかありました。 同じアプリケーションだけでなく、同じカテゴリの複数のアプリケーションに同じような脆弱性が見つかっている例もあります。 例えば「The
就職面接でプログラムの解読を求められた！ | POSTD
長文ですが、よかったら読んでください。 就職面接でプログラムの解読を求められました。そして、就職が決まりました。 皆さん、こんにちは。新しいブログを開設したので、私は今とても張り切っています。週に何度か記事を投稿するつもりです。 タイトルを見れば大体の話の内容は分かると思いますが、これから書くのは、トルコのアンカラで受けた就職面接の話です。 私が応募した職は「ソフトウェアセキュリティエンジニア」でした。面接中、面接官たちは非常に専門性が低い質問をしてきましたが、分かることもあれば分からないこともありました。 その後、その企業からメールが届き、保護および暗号化されたバイナリファイルが添付されていました（「解読してみろ」ということでしょう）。 帰宅後にファイルをダウンロードすると、ファイルを開くために聞かれたのはパスワードだけでした。面接官が私に課した課題は、そのパスワードを探すことでした。
2 段階認証は本当に安全なのか調べてみた | はったりエンジニアの備忘録
このブログを読んでいる人なら Google や AWS の 2 段階認証（マルチファクタ認証）を有効にしていると思います。もしパスワードが漏れてしまってもワンタイムパスワードを入力しないと認証されないので安心です。 有名どころのサービスでは使えるところが増えてきましたが、2 段階認証を有効にしていれば万全なのでしょうか。エンジニアである以上、その仕組みを理解したうえで自信を持って安全と言いたいところ。 というわけで、2 段階認証は本当に安全なのか仕様を紐解きながら調べてみました。 ワンタイムパスワードの仕様 ワンタイムパスワードを生成する仕様は HOTP と TOTP の 2 つがあり、RFC の仕様になっています（TOTP はドラフト段階）。 HOTP (HMAC-Based One-Time Password Algorithm) TOTP (Time-Based One-Time P
フロントエンドWeb戦略室 記事一覧 | gihyo.jp
第1回外部サイトに貼り付けるJavaScriptの作法―ポリシー、速度、セキュリティ、プライバシー（3） mala 2012-07-04 第1回外部サイトに貼り付けるJavaScriptの作法―ポリシー、速度、セキュリティ、プライバシー（2） mala 2012-07-03
#6 IT戦士 天野 仁史／こんにちはこんにちは！ Hamachiya2（後編） Webアプリ開発でもっとも重要なこと | gihyo.jp
小飼弾のアルファギークに逢いたい♥ #6IT戦士 天野 仁史／こんにちはこんにちは！ Hamachiya2（後編） Webアプリ開発でもっとも重要なこと 天野 仁史さん、Hamachiya2さん（はまちちゃん）との対談の後編です。 編集部注） 本対談は2007年3月に行われたものです。 撮影：武田康宏 優れたエンジニアって 弾：毎度おなじみの質問です。優れたエンジニアとして重要なのはどんなことでしょうか。タグは綴じようとか（笑）。 天：俺は自分1人でどこまで作れるかっていうことだと思います。上から下まで自分でどのくらい作れるか。そういう意味では、自分はまだまだかなぁと思うんですけど。 は：そういう人がそばにいたら、何でもお願いしたくなっちゃうかも。アイディアが湧いたら「こんなの作って」とかって。この人に言ったら、上から下まで全部できちゃうみたいな。 弾：いやでも何でもやら
bash の脆弱性 "Shell Shock" のめっちゃ細かい話 (CVE-2014-6271) - もろず blog
※(2014/10/1 追記) 脆弱性の番号を誤って CVE-2014-6721 と表記してしまっていました 正しくは "CVE-2014-6271" です 失礼致しました ※(2014/10/7 追記) 2014/10/7 14:00時点で Shell Shock への修正パッチは6個 公開されています 既に対応済みのシステムでもパッチの漏れがないか注意してください シェルに脆弱性が見つかったらしいです このコマンドを実行すると脆弱性があるバージョンかのチェックができるようです $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" 以下のように表示されたらアウトです vulnerable this is a test どうやら、このコマンドが正常に実行できるというのがこの脆弱性の正体らしく、 echo vuln
いますぐ使えるOpenID 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
本当は怖い文字コードの話 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
第11回 スクリプトインジェクションを防ぐ10のTips | gihyo.jp
前回はスクリプトインジェクションがなくならない理由を紹介しました。それをふまえて今回はスクリプトインジェクションを防ぐ10のTipsを紹介します。 デフォルト文字エンコーディングを指定 php.iniには、PHPが生成した出力の文字エンコーディングをHTTPヘッダで指定するdefault_charsetオプションがあります。文字エンコーディングは必ずHTTPヘッダレベルで指定しなければなりません。しかし、デフォルト設定ではdefault_charsetが空の状態で、アプリケーションで設定しなければ、HTTPヘッダでは文字エンコーディングが指定されない状態になります。 HTTPヘッダで文字エンコーディングを指定しない場合、スクリプトインジェクションに脆弱になる場合あるので、default_charsetには“UTF-8”を指定することをお勧めします。サイトによってはSJIS、EUC-JP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
脆弱性事例に学ぶセキュアコーディング「SSL/TLS証明書検証」編 (KOF2014)
