SSL通信の根本を揺るがす「SuperFish」問題をどう見るべきか
SSL通信の根本を揺るがす「SuperFish」問題をどう見るべきか：セキュリティクラスター まとめのまとめ 2015年2月版（1/3 ページ） PCにプリインストールされたソフトが通信に割り込み、その内容を全て見ていたかもしれない――2015年2月、レノボの「SuperFish」問題は大きな爪痕を残しました。 連載目次 2月と言えば情報セキュリティ月間改め「サイバーセキュリティ月間」です。脆弱性による大きなインシデントは発生せず、ほっとしていたのもつかの間、レノボのPCにSSL通信を書き換えるアドウエアが、レノボ自身の手によって仕込まれていることが明らかとなり、大きな騒ぎとなりました。 さらに、セキュリティクラスターの風物詩的なものとして長く見守られていたいわゆる「バリデーション論争」がついに終わりを迎えることとなります。 レノボのPCに「SuperFish」の凶悪なアドウエアが仕込まれ
Secure Sockets Layer - Wikipedia
アプリケーション層プロトコルへの適用[編集] TLSは特定のアプリケーション層プロトコルに依存しないため、HTTP以外にも多くのプロトコルにおいて採用され、クレジットカード情報や個人情報、その他の機密情報を通信する際の手段として活用されている。 既存のアプリケーション層プロトコルでTLSを利用する場合、大きく2つの適用方式が考えられる。まずひとつは、下位層（通常はTCP）の接続を確立したらすぐにTLSのネゴシエーションを開始し、TLS接続が確立してからアプリケーション層プロトコルの通信を開始する方式である。もうひとつは、まず既存のアプリケーション層プロトコルで通信を開始し、その中でTLSへの切り替えを指示する方式である。切り替えコマンドとしてSTARTTLSが広まっているため、この方式自体をSTARTTLSと呼ぶこともある。 前者はアプリケーション層のプロトコルをまったく変更しなくてすむこ
第14回 減らないSQLインジェクション脆弱性 | gihyo.jp
SQLインジェクション脆弱性を狙った大規模な攻撃が繰り返し行われ、数万から数十万ページが改竄される事件が何度も発生しています。SQLインジェクションは簡単に対策できる脆弱性ですが、未対策のアプリケーションが多く利用されています。外部からの脆弱性の検出も容易であるため、現在でもWebアプリケーション脆弱性の代表的存在です。 SQLインジェクション脆弱性が無くならない理由には以下のようなものが考えられます。 過去のコードやアプリケーションの再利用 基本的なセキュリティ知識不足 セキュアコーディングプラクティスの未実施 コード監査の不在 SQLインジェクション脆弱性の発見だけを目的にコード監査を行うことはあまりありませんが、SQLインジェクション脆弱性のコード監査は比較的簡単です。MySQLモジュールまたはPostgreSQLモジュールを利用している場合を例に紹介します。 本題に入る前にSQLイ
第1回 Ajaxとクロスサイトスクリプティング | gihyo.jp
初回はWeb2.0の中核技術ともいえるAjaxを見ていきたいと思います。 Ajaxのセキュリティについて考えていきますが、その前にAjaxについて簡単におさらいしてみましょう。 AjaxとはAsynchronous JavaScript XMLの略であり、一言で言えばJavaScriptとXMLを使って非同期に通信するということです（XML以外の形式が使われることも多くなりました）。通信を非同期にすることで、何か処理をする場合にいちいち待たなくても次の処理に移ることができます。その結果、ユーザを待たせずに多くの処理を行えるようになりました。また、画面全体を再読み込みする必要がなくなったことも、使い勝手の向上した理由です。 Ajaxの動作 それでは簡単なサンプルコードでAjaxの動作を見ていきたいと思います（リスト1）。これらはAjaxの入門サイトや書籍で一番最初に出てくるコードです
EximのGHOST脆弱性の影響とバリデーションの関係
追記(2015/2/6) 大垣さんから訂正依頼のコメントを頂いておりますので合わせてお読みください。徳丸としては特に訂正の必要は感じませんでしたので、本文はそのままにしています。そう思う理由はコメントとして追記いたしました。 (追記終わり) 大垣さんのブログエントリ「GHOSTを使って攻撃できるケース」を読んだところ、以下のようなことが書いてありました。 1. ユーザー入力のIPアドレス（ネットワーク層のIPアドレスではない）に攻撃用データを送る。 2. バリデーション無しで攻撃用の不正なIPアドレスをgethostbyname()に渡される。 3. ヒープオーバーフローでヒープ領域のメモリ管理用の空きサイズを改竄する。 【中略】 どんなソフトウェアが危ないのか？ ユーザー入力のIPアドレスをバリデーションしないでgethostbyname()を使用している。 インタラクティブな動作を行っ
ブラウザ上でMarkdownを安全に展開する - 葉っぱ日記
不特定のユーザーが入力したMarkdownをブラウザ上でJavaScriptを使ってHTMLに変換するという場面においては、JavaScriptで変換してHTMLを生成するという処理の都合上どうしてもDOM-based XSSの発生を考えないわけにはいかない。かといって、MarkdownをパースしHTMLを生成するという処理すべてをXSSが存在しないように注意しながら自分で書くのも大変だし、markedやmarkdown-jsなどの既存の変換用のJSを持ってきてもそれらがXSSしないかを確認するのは結構大変だったりする。 そういった場合には、Markdownから生成されたHTMLをRickDOMを通すことで、万が一HTML内にJavaScriptが含まれていたとしてもそれらを除外し、許可された要素、許可された属性だけで構築された安全なHTMLに再構築することができる。さらに、そうやって生成
GHOST 脆弱性は如何様に使うのか | Webシステム開発／教育ソリューションのタイムインターメディア
先日 GHOST と呼ばれる glibc の脆弱性が発表された。なんでも、「リモートから任意のコードを実行できる可能性がある」らしいではないか。しかも様々なプログラムで利用されているライブラリ部分の問題とあって、影響範囲がとても広い。なかなか厄介なことである。 はて、しかし一体全体どうやってリモートから任意のコードを実行しようというのだろう？ 話を聞くに、たかが数バイトの情報を範囲外のメモリに書き込める可能性があるだけだという。実際それだけのことでサーバーの乗っ取りなどできるものなのだろうか。そんなわけで、その疑問に答えるべく、本記事では以下の URL で解説されている実際の攻撃方法を若干端折って紹介してみようと思う。 http://www.openwall.com/lists/oss-security/2015/01/27/9 なお、本記事はこの脆弱性そのものに対する緊急度などについて言
なぜPHPアプリにセキュリティホールが多いのか?：第1回 CVEでみるPHPアプリケーションセキュリティ｜gihyo.jp … 技術評論社
PHPアプリケーションの脆弱性は本当に多いのか？ アプリケーションの脆弱性を調べるには、CVEを参照するのが簡単です。 CVEとは、NISTが公開しているソフトウェアの脆弱性データベースです。脆弱性を一意に特定できるIDを付与することを目的としています。Webアプリケーションの脆弱性もCVEに登録されています。CVEに2006/12/31に登録されたアプリケーションの脆弱性の数（同じアプリケーションは除く）は次の通りでした。日によって登録される脆弱性の数は異なります。12月31日は比較的多くの脆弱性が登録されました。 通常どおりPHPアプリケーションの脆弱性が目立ちます。特にこの日は同じアプリケーションで複数の脆弱性が登録されていたものがいくつかありました。 同じアプリケーションだけでなく、同じカテゴリの複数のアプリケーションに同じような脆弱性が見つかっている例もあります。 例えば「The
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 特有の機能でもダン
/etc/hostsに 127.0.0.1 cmertv.com を足した - mizchi's blog
こういうの ゼルダ、Portal、ソニックなど。ゲーム音楽をバンジョーで演奏 ｜ コタク・ジャパン 動画広告、記事読んでる横で15s程度の動画が流れるくらいだったら、そんなロースペックなマシン使ってるわけでもないしどうでもいいんだけど、突然大音量で流されると心の用意出来てないしオフィスいるかもしれないしで、最高にブチ切れそうになる。 止める方法がわからない場合、ブラウザごと落とすことを止むを得ない。 しかもヘッダに近い場所じゃなくて、記事末尾とかにおいてるサイトも多い。cmerが悪質なのは、わかったところで再生を止める方法が提供されてないこと。悪質すぎる。 個人的には積極的に不買運動せざるを得ない。とりあえずこれが原因で kotaku.jp をRSSリーダーから外した。 「テレビCMの再価値化を目指す」――CMer TV 五十嵐社長に聞く | AdverTimes（アドタイ）
就職面接でプログラムの解読を求められた！ | POSTD
長文ですが、よかったら読んでください。 就職面接でプログラムの解読を求められました。そして、就職が決まりました。 皆さん、こんにちは。新しいブログを開設したので、私は今とても張り切っています。週に何度か記事を投稿するつもりです。 タイトルを見れば大体の話の内容は分かると思いますが、これから書くのは、トルコのアンカラで受けた就職面接の話です。 私が応募した職は「ソフトウェアセキュリティエンジニア」でした。面接中、面接官たちは非常に専門性が低い質問をしてきましたが、分かることもあれば分からないこともありました。 その後、その企業からメールが届き、保護および暗号化されたバイナリファイルが添付されていました（「解読してみろ」ということでしょう）。 帰宅後にファイルをダウンロードすると、ファイルを開くために聞かれたのはパスワードだけでした。面接官が私に課した課題は、そのパスワードを探すことでした。
フロントエンドWeb戦略室 記事一覧 | gihyo.jp
第1回外部サイトに貼り付けるJavaScriptの作法―ポリシー、速度、セキュリティ、プライバシー（3） mala 2012-07-04 第1回外部サイトに貼り付けるJavaScriptの作法―ポリシー、速度、セキュリティ、プライバシー（2） mala 2012-07-03
2 段階認証は本当に安全なのか調べてみた | はったりエンジニアの備忘録
このブログを読んでいる人なら Google や AWS の 2 段階認証（マルチファクタ認証）を有効にしていると思います。もしパスワードが漏れてしまってもワンタイムパスワードを入力しないと認証されないので安心です。 有名どころのサービスでは使えるところが増えてきましたが、2 段階認証を有効にしていれば万全なのでしょうか。エンジニアである以上、その仕組みを理解したうえで自信を持って安全と言いたいところ。 というわけで、2 段階認証は本当に安全なのか仕様を紐解きながら調べてみました。 ワンタイムパスワードの仕様 ワンタイムパスワードを生成する仕様は HOTP と TOTP の 2 つがあり、RFC の仕様になっています（TOTP はドラフト段階）。 HOTP (HMAC-Based One-Time Password Algorithm) TOTP (Time-Based One-Time P
本当は怖い文字コードの話 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
プログラマとして30年以上の経験から得た教訓 | POSTD
私は、プログラマとして30年以上仕事をしてきた中で、学んだことがあります。そのいくつかを以下にご紹介します。もっと挙げることもできますよ。 実物を見せないと、顧客の希望は分からない。 このことは最初の仕事で学びました。顧客は、実物を見るまでは、何が本当に必要なのかがよく分かりません。言葉で長々と説明するよりも、機能検証のためのプロトタイプを提示する方が確実に役立ちます。 十分な時間があれば、あらゆるセキュリティは破られる。 現代社会において、セキュリティを保つことは信じられないほどの難題となっています。プログラマは常に完璧を求められますが、ハッカーは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
ビッグデータの倫理
ビッグデータへの注目が過熱する一方、そこに含まれる個人情報の取り扱いについて、さまざまな議論や問題が巻き起こっています。本書はビッグデータを取り扱う業務に携わる読者に向けて、ビッグデータを扱う際の倫理について考え、議論を行う枠組みについて、「アイデンティティ」「プライバシー」「オーナーシップ」「信用」という4つの軸とともに紹介します。「倫理」という、個別性が高く、明快な答えの見つけづらい問題について、読者自身や組織の中で実りのある議論をする一助となるでしょう。なお本書はEbookのみの販売となります。 まえがき 1章 ビッグデータのビッグインパクト なぜビッグデータなのか？ ビッグデータは何を強制するのか？ ビッグデータは倫理的に中立である 何をすべきかを尋ねてはいけない 重要な概念と用語 2章 価値と行動 価値を明確に表現する 価値を行動に変える 倫理的判断ポイント 3章 現在の業務 研
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
脆弱性事例に学ぶセキュアコーディング「SSL/TLS証明書検証」編 (KOF2014)
安全なPHPアプリケーションの作り方2014
連載：なぜPHPアプリにセキュリティホールが多いのか?｜gihyo.jp