UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。
UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。
更新履歴 DNS拡張EDNS0の解析 Linuxカーネルをハッキングしてみよう Windowsシステムプログラミング Part 3 64ビット環境でのリバースエンジニアリング Windowsシステムプログラミング Part2 Windowsシステムプログラミング Part1 Contents インフォメーション 「TCP/IPの教科書」サポートページ 「アセンブリ言語の教科書」サポートページ 「ハッカー・プログラミング大全 攻撃編」サポートページ ブログ(はてな) BBS メール このサイトについて テキスト 暗号 詳解 RSA暗号化アルゴリズム 詳解 DES暗号化アルゴリズム crypt() アルゴリズム解析 MD5 メッセージダイジェストアルゴリズム crypt() アルゴリズム解析 (MD5バージョン) TCP/IP IP TCP UDP Header Format(IPv4) Ch
最近、何処の会社でもセキュリティに関してうるさく言われているかと思います。自分としても今まで気を遣ってきていたつもりではあります。しかしながら、 なぜSSL利用をケチるのか:IT Pro SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも 安全なWebサイト設計の注意点 を読んでみて、お恥ずかしい限りですが勘違いしていた部分もありました。実際、Amazon とか Yahoo! のログイン画面を見ても、デフォルトが http によるアクセスになっていたりして、メジャーどころでも最新の注意が払われている訳ではないのだなぁ〜と思ったり・・・。本当は全ページ SSL が理想とは知りつつも、SSL の処理負荷の高さ故に、ついついケチったページ遷移にしまうからなのでしょう。。。自分含めて。 自分への情報もかねて、上記ページに記載されている、31箇条の鉄則と最近の事情を加
本ページの情報は、2016年10月時点のものです。2023年10月に再構成をいたしました。 なお、内容に変更はありません。 2016年10月版 2002年2月に「Webプログラマコース」と「製品プログラマコース」、2007年の6月に「Webアプリケーション編」、9月に「C/C++編」と分けて公開してきた講座のうち、原則を中心として共通的なものをまとめて2016年10月に再編しました。 なお、資料内の参照先はすべてサイトリニューアル前のURLであるため、リダイレクトを設定しています。 セキュア・プログラミング講座(2016年10月版/2017年6月一部修正)(PDF:2.3 MB) 2007年版 「ソースコード検査技術の脆弱性検出能力向上のための研究」(注釈1)を実施した一環として取りまとめた内容を、2002年から公開していたセキュア・プログラミング講座(旧版)の改訂版(2007年版)として
JavaScript: 触って分かる公開鍵暗号RSA 2004年 2月 4日 記事ID d40204 公開鍵暗号RSAの各面について。 本に書いてあるような理論的説明でなく、 実地に体験しながら、具体的に見ていきましょう。 JavaScript で実装したRSA暗号系 PigPGP 0.2.3 日本語版 を使います。 このデモは、内部で実際に行っている演算の様子をガラス張りにして見せてくれます。 初めに 例えばパソコンについて理解するのに、本を読んだだけで十分に納得がいくものでしょうか。 やはりパソコンについてよく分かるようになるにはパソコンをいじってみるのがいちばんでしょう。 同じように、ここではRSA暗号について実感として分かることが目的ですから、 RSA暗号系を自分の手でいじってみるのがいちばんです。 PigPGP 0.2.3 日本語版がそれです。 これは JavaScript で実
Checklist for Securing PHP Configuration | Ayman Hourieh's Blog Inside is a check list of settings that are intended to harden the default PHP installation.PHPセキュリティチェックリスト。 PHPの設定ファイルによってはセキュリティ的によろしくない場合もよくあることなので、そのチェックを行うためのリスト。 allow_url_fopen、register_globals など、一連のphp.iniに関する設定のチェックする際に役立ちます。
JavaScript 検討、全てのサイトでGM_xmlhttpRequestを使う 上記エントリのコードは脆弱で、GreasemonkeyのGM_xmlhttpRequestを予期しないコンテンツウィンドウから奪われる可能性があることを、Days on the Moonのnanto_viさんにメールにて教えていただきました。貴重なアドバイスを頂き、深く感謝しております。 具体的には、gmXMLHTTPRequestの__parent__プロパティから、Greasemonkeyスクリプトのコンテキストを取得され書き換え、APIキーをコンテンツウィンドウにコントロールし乗っ取ることができます。サンプルコードは以下です。 gmXMLHTTPRequest.__parent__.API_KEY = 'ABC'; GM_XHR_API_KEY = 'ABC'; gmXMLHTTPRequest({
Googleの一般検索でも、社外秘情報の入ったExcelを検索したらいろいろ出てきた(参考 、 公開Webサーバから機密情報を引き出す「Googleハッキング」の脅威と、その対策)といった話もあるし、つい最近はGoogle Calendarで明らかに公開情報じゃないいろんな人の予定が検索できるという指摘も話題になった。 ということで、昨日リリースされたGoogleコード検索でも、さっそく色々な「ヤバイ」指摘が。 kottke.org では以下のような検索例が 圧縮アプリケーションの暗号生成部分のソース パスワードを埋め込んだブログシステムのソース バッファーオーバーフロー脆弱性がありそうなソース 公開されるべきでない、と書いてあるソース 愚痴ったり、罵ったり、馬鹿にしたりというコメント 有名プログラマーの名前での検索 また、PHPのセキュリティといえばこの人の Chris Shiflett
情報データを様々な攻撃から守る安全なシステムを構築するためには,セキュリティ技術の理解が欠かせない。ここではセキュリティ確保の中核技術とも言える,「共通鍵/公開鍵暗号」,「デジタル署名」,「バイオメトリクス」といった暗号・認証技術を取り上げ,基本的な仕組みや利用動向を解説する。 今や日本の企業のほぼすべてがインターネットを利用しており,一般家庭を見ても利用人口は約5割に達するという。ITは水道や電気と並ぶ,欠かすことのできない社会インフラとなった。 しかし,コンピュータの数が増え,ユーザーが様々なサービスを享受できるようになった一方で,深刻な問題が発生してきた。それは,一つひとつのコンピュータに監視の目が行き届かなくなり,悪意のある人間による不正操作が行われやすい環境になってきたということだ。実際に,コンピュータ上のデータが盗まれたり,改ざんされるといった事件が多発するようになり,連日のよ
マルウェアの解析対策を無効にするAnti-Anti-Debuggingツールを開発 [2007年11月21日] 最近のマルウェアはどれも様々な解析対策が施されており,数年前と比べて解析がやや面倒になっています。攻撃者はマルウェアの発見を困難にさせたり,セキュリティベンダーらによる解析を遅らせたりするため様々な解析対策を実装しています。今回は,このデバッガ検出を無効にする方法を紹介します。 日本に戻って参りました [2007年08月20日] 先月,eEye Digital Securityを退職し,長かったカリフォルニアの生活を終えて日本に戻って参りました。そして,eEyeでセキュリティスキャナRetinaのエンジン開発の他,様々なリサーチを行っていた金居,eEyeの顧問を務めていた野澤とともに,神楽坂で新しい会社を設立致しました。 ネットワークインタフェースカードのファームウェアで動作
■ クロスサイトリクエストフォージェリ(CSRF)の正しい対策方法 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。 クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。 前提 ログインしていないWeb閲覧者に対するCSRF攻撃(掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為)はここでは対象と しない。 ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く