このウェブサイトは販売用です! atword.jp は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、atword.jpが全てとなります。あなたがお探しの内容が見つかることを願っています!
このウェブサイトは販売用です! atword.jp は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、atword.jpが全てとなります。あなたがお探しの内容が見つかることを願っています!
ブログ パスワード認証 閲覧するには管理人が設定した パスワードの入力が必要です。 管理人からのメッセージ 閲覧パスワード Copyright © since 1999 FC2 inc. All Rights Reserved.
GENOウイルス対策情報まとめ、GENOウイルスチェッカー更新情報 2009 05/17 といってもウイルス側の挙動がかなり高度なので、誤判定はあります 万が一の事があってはいけないのでかなり判定厳しめに設定してあります。 ご理解の程よろしくお願いします 2009 05/17 いそいで作ったので判定機能以外はぐちゃぐちゃ 2009 05/17 開設 ウソクソ情報 ■javascriptを切ってても感染する(5/17現在) 今の時点ではウソだが将来的に、pdf or swfをjavascript経由せずに直接読み込ませるタイプのものが出てきたらアウト とにかく↓のアドビ関連のアップデートを怠らないこと。 GENOウイルス対策 ■adobe readerを9.1.1にアップデートする(9.1:9.1,0では駄目) http://ardownload.adobe.com
2024/04/08 紅麹関連製品の使用中止のお願いと自主回収のお知らせ(第9報) 2024/04/05 紅麹関連製品の使用中止のお願いと自主回収のお知らせ(第8報) 2024/04/01 紅麹関連製品のインターネットからの返品のお申し込みについて 2024/04/01 紅麹関連製品の使用中止のお願いと自主回収のお知らせ(第7報) 2024/03/29 紅麹関連製品の使用中止のお願いと自主回収のお知らせ(第6報) 2024/03/28 紅麹関連製品の使用中止のお願いと自主回収のお知らせ(第5報) 2024/03/27 紅麹関連製品の使用中止のお願いと自主回収のお知らせ(第4報) 2024/03/26 紅麹関連製品の使用中止のお願いと自主回収のお知らせ(第3報) 2024/03/25 紅麹関連製品の使用中止のお願いと自主回収のお知らせ(第2報) 2024/03/22 紅麹関連製品の使用中止の
(Last Updated On: 2018年8月13日)追記:より新しい情報については間違いだらけのHTTPセッション管理とその対策をどうぞ。 PHPには広く知られているにも関わらず放置されている既知のセキュリティ脆弱性が幾つかあります。その一つがセッションモジュールのセッションアダプション(Session Adoption)脆弱性です。この脆弱性は現在広く利用されているWebアプリケーションの安全性に、非常に大きな影響を与える脆弱性です。 セッションアダプション脆弱性とはセッション固定化攻撃を可能とする脆弱性の一種です。セッションアダプションに脆弱なセッション管理システムは、ユーザ(ブラウザ)が送信してきた未初期化のセッションIDを受け入れ、セッションを初期化してしまいます。PHPに限らず、RailsやJavaのフレームワーク等、多くのWebフレームワークに発見されている脆弱性です。
前回に引き続き、今回も文字エンコーディングとセキュリティをテーマに解説します。前回は壊れた文字エンコーディングを利用した攻撃、文字エンコーディングを誤認識させる攻撃を紹介しました。今回はSJIS特定の問題を簡単に紹介します。 文字エンコーディングのエスケープ方式を利用する方法 ほとんどの文字エンコーディングは、マルチバイト文字の中に“\”などの特殊文字を含みません。しかし、例外があります。Shift_JISでは“\”がマルチバイト文字に含まれるので、これが原因で脆弱性が発生する場合あります。 SJISの“表” <?php echo rawurlencode(mb_convert_encoding('表', 'SJIS', 'UTF-8')); ?> 出力 %95%5C “%5C”は“\”です。“\”は文字列のエスケープなどに利用される特殊文字です。addslashes関
IT系の勉強会は日々、全国各地で開催されている。「IT勉強会カレンダー」の管理人で、自らも勉強会を運営しながらさまざまな勉強会に足を運ぶ筆者が、毎月面白い勉強会をピックアップする。 第1回|1 2|次のページ 皆さん、あけましておめでとうございます。 忘年会や新年会はいかがでしたか? 「IT勉強会カレンダー」に登録された内容をご覧になっていただければ分かりますが、12月開催予定の335件の勉強会情報(本稿執筆時点)のうち、なんと25件も「忘年会」の記述がありました。1月の勉強会情報にも「新年会」を含むものがありますね。年末年始の勉強会は、そういった楽しみ方もアリかもしれません。 ■「門外不出」のセキュリティ系勉強会 IT勉強会カレンダーで日本全国の勉強会を眺めてみると、開発系の勉強会が数多く目につく一方で、セキュリティ系は目立ちません。しかし、セキュリティ全般を取り扱っている勉強会に加え、
(Last Updated On: 2018年8月13日)これから紹介する脆弱性はPHP 5.2.6で修正されています。修正された、とは言え注意が必要です。 PHPは古くからシェルコマンドとシェル引数をエスケープ処理する為に、escapeshellcmd関数とescapeshellarg関数を提供しています。 この関数はマルチバイト文字にも対応しているのですが、ビルドや環境によっては対応できていないときがあります。 escapeshellcmd/escapeshellarg関数ではC99で定義されてるmblen関数を利用しています。一般的なUNIX系システムではmblen関数は利用可能でると考えられるので、問題となる事は少ないと思いますが、PHPではphp_mblenマクロが以下のように定義されています。 #ifndef HAVE_MBLEN # define php_mblen(ptr,
WordPressのセキュリティをアップする11のポイントをPro Blog Designのエントリーから紹介します。 11 Best Ways to Improve WordPress Security セキュアなデータベースを構築する。 他のアプリケーションと共有しないWordPressのためだけのデータベースを使用する。 データベースへのアクセスは限定する。 データベースのパスワードは強固なものにする。 「wp-config.php」の設定。 セキュリティキーを設定する。 セキュリティキーツール 1.1でランダムなキーが生成されます。 テーブル名の接頭辞($table_prefix)を「wp_」以外のものに変更する。 管理画面のユーザー名にデフォルトの「admin」を使用しない。 ユーザー名はphpMyAdminなどで変更できます。 管理画面のパスワードは複雑なものにする。 英数記号
文字エンコーディングを正しく、厳格に取り扱わないと、システムのセキュリティに大きく影響します。しかし、広く利用されているアプリケーションでも、大手サイトでも文字エンコーディングを不適切に取り扱っているケースは少なくありません。 今回から4回に分けて、セキュリティと文字エンコーディングをテーマに、Webアプリケーションがどのようなセキュリティ対策を取るべきか解説します。攻撃方法の解説ではないので具体的な攻撃方法は解説しませんが、どのように攻撃されるのかは簡単に解説します。 文字エンコーディングは厳格に扱わなければならない 問題の解説を始める前ですが、いきなり結論から入ります。それは、非常に簡単な原則であるにも関わらず、あまり多くのサイトやアプリケーションで守られていないからです。 文字エンコーディング取り扱いの原則文字エンコーディングは厳格に取り扱い、不正な文字エンコーディングを検出した場合
先日の日記書籍「はじめてのPHPプログラミング基本編5.3対応」にSQLインジェクション脆弱性 - 徳丸浩の日記(2008-10-29)にて、はじめてのPHPプログラミング 基本編―5.3対応を取り上げた際に、『その「ゆるさ」のゆえんはおいおい報告する』と予告していた。書くネタは決まっていたのだが、多忙のために果たせていなかったが、今日から少しずつ報告しよう。まずはデータベースの格納場所についてだ。 本書ではSQLの説明にSQLiteを使用している。SQLiteは、常駐サービス/デーモンがなく、アクセスライブラリが直接単一のデータファイルを参照する実装となっていて、早い話がACCESS(.mdb)のような実装だ。このデータファイルの置き場所が問題だ。 本書には、以下のような記述がある。 現時点でindex.phpとSQLiteのデータベースファイルminiblogが同じディレクトリに存在し
今読み返すと、あちこちに変な日本語が混じっていますね。 訂正するのも嫌らしいのでそのままにしておきます。 はてなブックマークというサービスで、当エントリーに対してついたコメントに返信していきます。 このエントリーには、「XSSの危険性をわかっていない人に理解してもらう」というのが前提としてありました。 そして、「技術の疎い人にも理解して動いてもらう」という願いもありました。 このために、「多少の誤解を与えたとしてもなんとなく理解してもらう」事を重要視しています。 これを踏まえて以下記述します。 「#」ではじまるのがはてなブックマークのコメントです。 #2008年10月24日 g616blackheart ガードが堅いと言われた……どうしてだろう? #2008年10月24日 anigoka なんかガードが堅いて言われちゃったんだけど、なに,オレが非コミュだって言いたいの!? 申し訳ないです。
※ src: 画像の場所を指定する属性。相対パスではなくURLで書けば、他のドメインにある画像を表示することも可能。つまりURLに対してGETリクエストを行う(閲覧者に行わせる)お手軽な手段とも言え、これを用いてなんらかの攻撃が行われることもしばしば。 まとめ このように、imgタグなどによって、閲覧者のブラウザからどこかのURLへ任意のリクエストを「送らせる」ことは簡単にできてしまいます。しかも、それで発生するリクエストは、閲覧者自身がリンクをクリックしたときとなんら変わりはありません。では、これを攻撃として用いられた場合(つまりCSRF)、Webプログラム側ではどのように防げばよいのでしょう。 きっとまっさきに思いつくのは、「POSTリクエストを使うようにする」、あるいは「リファラヘッダ(リンク元が記載されているヘッダ行)のチェックを行う」などでしょうか。しかしそれだけでは不
はい! こんにちは! 今日は珍しくセキュリティについて一言です! タイトルにある通り、 XSSはそのサイトを信頼している人が多いほど脅威になりうる ってことなんだけど…。これだけだと、あたりまえっぽいよね。 まずXSS脆弱性ってなに? って人のために簡単に説明しちゃうと、これ サイトを作った人以外の人でも、好きなスクリプトを実行できちゃう状態 ってことなんだよね。 でもよく考えてみてほしい。 スクリプトが実行できる。へんなスクリプトが実行されちゃうかもしれないページ。 これって別に、「ふつうにスクリプトを許可されている、そこらへんのブログやホームページと同じ」じゃない? いや、微妙に違うかな。 違う点はひとつ。 スクリプトを埋め込めるのが「サイトの管理者オンリー」なのか「誰でも」なのかの違いがあるんだよね。 … じゃあ、「名もなきサイトの管理者」と「誰でも」の違いってなんだろう? なんだろ
SQLインジェクション脆弱性を狙った大規模な攻撃が繰り返し行われ、数万から数十万ページが改竄される事件が何度も発生しています。SQLインジェクションは簡単に対策できる脆弱性ですが、未対策のアプリケーションが多く利用されています。外部からの脆弱性の検出も容易であるため、現在でもWebアプリケーション脆弱性の代表的存在です。 SQLインジェクション脆弱性が無くならない理由には以下のようなものが考えられます。 過去のコードやアプリケーションの再利用 基本的なセキュリティ知識不足 セキュアコーディングプラクティスの未実施 コード監査の不在 SQLインジェクション脆弱性の発見だけを目的にコード監査を行うことはあまりありませんが、SQLインジェクション脆弱性のコード監査は比較的簡単です。MySQLモジュールまたはPostgreSQLモジュールを利用している場合を例に紹介します。 本題に入る前にSQLイ
(Last Updated On: 2008年9月13日)大規模なWebサイト構築を行っている方ならF5にお世話になっている方も多いでしょう。F5のブログで私と全く同じ意見のブログ – Why it’s so hard to secure JavaScriptを見つけたので紹介します。 Webクライアント側でのページフィルタリングは有用なのか?でシグニチャベースのページフィルタリングは有用では無いと書きましたが、WAF(Web Application Firewall)を販売しているF5の方も同じ考えです。 As we learned from preventing SQL injection and XSS, attackers are easily able to avoid detection by these systems by simply adding white space
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く