ma<s>atokinugawaの日記
* GNU C Compiler * GNU Make * GNU C Library (including development headers) * zlib (including development headers) * OpenSSL (including development headers) * libidn (including development headers) KnownIssues – skipfish –参照。 私の環境では、libidnがなかったので、yumで入れました。 さて、skipffish本体のインストールを行いましょう。 ※最新のダウンロードはこちらのページを参照ください。 http://code.google.com/p/skipfish/ # wget http://skipfish.googlecode.com/files/skipfi
こんにちは。 VPSのレンタルサーバで、RHEL、PHP5、Apache2でサイトをこれからつくる予定です。 まずはセキュリティ的な部分を、片付けようと思い、 そこで、まずは、XSS対策をしようと思いました。 で、PHP と Web アプリケーションのセキュリティについてのメモ http://www.asahi-net.or.jp/~wv7y-kmr/memo/php_security.html を見まして<ユーザが HTML タグやスタイルシートを記述できるようにしたい場合のクロスサイトスクリプティング対策としては、「はてなダイアリーXSS対策が」参考になります> とあったので、 「はてなダイアリーXSS対策」 http://hatenadiary.g.hatena.ne.jp/keyword/%E3%81%AF%E3%81%A6%E3%81%AA%E3%83%80%E3%82%A4%E
XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます (編集部) 次は、JSONにおけるセキュリティ対策 皆さんこんにちは、はせがわようすけです。第4回「[気になる]JSONPの守り方」はJSONPについて説明しましたので、今回は「JSON」についてもセキュリティ上注意すべき点について説明します。 JSONは、XMLHttpRequestで受け取り、JavaScript上でevalするという使い方が一般的です。 まずはサーバ側から送られる情報と、クライアント側での処理、それぞれの内容を見ておきましょう。 [サーバ側] HTTP/1.1 200 OK Content-Type: application/json; charset=
この1~2年で、ウェブサイトの脆弱性を狙った攻撃が急増している。特に、2008年3月ごろから「SQLインジェクション」攻撃によるホームページの改ざんやサイトへの不正コードの設置が多発した。このような状況のなかで、(財)地方自治情報センター(LASDEC)では、ウェブアプリケーションの脆弱性を診断するサービスを提供している。本稿では、地方自治体の現状とLASDECの取り組みを解説する。 (百瀬 昌幸=(財)地方自治情報センター 主任研究員) 地方自治情報センター(LASDEC)では、地方公共団体の情報セキュリティを支援する各種事業を展開している。平成19年3月には自治体セキュリティ支援室を発足し、以来今年で3年目を迎えた。こうした事業の1つが、「ウェブ健康診断」であり、当室が平成19年度から地方公共団体を対象に実施している事業(無償)だ。本事業では、地方公共団体の公式ホームページをはじめ、図
Rails 2系のXSS脆弱性を修正するパッチが先日公開されました。 4日(米国時間)、Ruby on Railsの2系すべてのバージョンにXSSの脆弱性があることがRiding Rails: XSS Vulnerability in Ruby on Railsにおいて発表された。特定のUnicode文字列を使ってチェックをくぐり抜け、任意のHTMLを送り込まれる危険性がある。なおRuby 1.9系で動作しているアプリケーションはこの影響を受けない。 http://journal.mycom.co.jp/news/2009/09/07/048/index.html この件に関して、大垣さんは次のように説明しています。 RoRの脆弱性に関連してRuby1.9では安全、と解説されていますが、それはRuby1.9は不正な文字エンコーディングを受け付けないからです。 何故かあたり前にならない文字エ
2009年9月16日、W2Cマークアップエンジニア・ワーキンググループでお話しした「マークアップエンジニアが知っておきたい3つの脆弱性」に関するサポートページです。とりあえず資料がダウンロードできます。 資料ダウンロードプレゼンテーション資料の PDF 版がダウンロードできます。 bakera_w2cWG.pdf (PDFファイル 487KB) 無断での再配布はご遠慮ください。また、資料内に含まれる画面キャプチャは全て削除されていますので、一部不自然な空白があります。 以下に若干の補足があります。 マークアップエンジニアが知っておきたい3つの脆弱性:補足 参考サイト話の中で触れたり、参考にしたりしたサイトです。 情報処理推進機構 (www.ipa.go.jp)経済産業省告示「ソフトウエア製品等脆弱性関連情報取扱基準」(PDF) (www.meti.go.jp)ソフトウェア等の脆弱性関連情報
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト(言語、フレームワークなど)か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
マルチバイト文字列の先行文字列埋め込みによる攻撃については、長谷川さんによる、http://gihyo.jp/admin/serial/01/charcode/0006 を参照いただくこととして、この記事に書かれていない、とりあえずの間に合わせ的な保険的対策について書いてみたいと思います。 なお、攻撃を「完全に防止できる」ということは証明できませんが、十分に難易度を高めることが可能であると思います。 処置は簡単です。「=」を、数値文字参照化してHTMLに出力するというものです。これにより、onイベント属性の追加が困難になることでしょう。HTMLの各属性をダブルクォート(など)で囲むことを徹底しておくほうがよいことはもちろんですが、時間がかかる場合にはとりあえず、この保険的対策をほどこしてからじっくりと腰を落として本来行うべき対策を行うとよいかもしれません。 ※この手法はXSSが有名になりは
Tech sovereignty has become a looming priority for a number of nations these days, and now, with the demand for compute power at its highest level yet, a startup working… It’s not the sexiest of subject matters, but someone needs to talk about it: The CFO tech stack — software used by the chief financial officers of the world — is ripe for disruption. That’s according to Jonathan Sanders, CEO and
以下のどれが実行可能なのでしょうか?IE8ないしIE6で。 [location(name)] +location(name) location(name)? true : false typeof location(name) location(name)|1 !location(name) ~~location(name) /(?!)/(location(name)) 最後のやつが一番わけわかんない。エラー吐きながらもってところで。個人的には三項演算子のやつとかtypeofキーワードのやつとかが綺麗ゲでにんまりします。typeof って、あたかも関数みたいだけど違う、括弧つかわずにパラメータ渡ししている風情があるのかなぁ。/(?!)/って関数じゃない(もじら拡張をIEは持たないから)なので()でlocation(name)を受けられない、だけれども、評価してしまう…という道筋でしょうか?
I bet 10 years ago none of us thought that 140 characters would change the landscape of Social Media quite so much. However, with close to 289,000,000 active users sending around 6,000 tweets every second Twitter has proven its critics wrong. Obviously, having gotten over the fact that 10 years of Twitter makes us all feel very old, we had to do something to mark this special day and we have had
文字コードが引き起こすセキュリティ上の問題として、もっとも興味深いもののひとつである、Unicodeから他の文字コードへの「多対一の変換」で引き起こされる問題点について、今回と次回で説明します。 ご存じのとおり、Unicodeには非常に多数の文字が収録されていますが(現在最新版のUnicode 5.1.0では100,713文字が収録されているそうです)、Unicodeから他の文字コードへの変換においては、互換性や可読性の維持のためか、複数のUnicodeの文字が他の文字コードでは単一の文字に変換されることがあります。 この「多対一」の変換が、開発者も想定していなかったような問題を引き起こす原因となることが多々あります。 具体的な例として、Windows上でのUnicodeからの変換について説明します。 Windows上でのUnicodeからShift_JISへの変換 Windows上で
-ウェブサイト運営者は脆弱性対策情報を収集し、バージョンアップを!- 最終更新日 2009年8月20日 掲載日 2009年8月20日 IPA(独立行政法人情報処理推進機構、理事長:西垣 浩司)は、オープンソースの全文検索システム「Namazu」(開発者:Namazu Project)の脆弱性について、「既に脆弱性対策を施したバージョンが公表されているにも関わらず、未適用のウェブサイトがある」旨の届出が増加していることから、本ソフトウェアを利用しているウェブサイト運営者に対し、迅速なバージョンアップ実施を呼びかけるため、「注意喚起」を発することとしました。 2008年8月頃から、Namazuを使用している複数のウェブサイトに対して、「開発者から脆弱性対策を実施したバージョンが既に公表されているのにも拘らず、ウェブサイト運営者がそのバージョンを適用していないのではないか?」という旨の届出が増加
T.Teradaさんによる実例を拝見して 2009-07-18のT.Teradaさんの日記の『括弧なしのXSS』という題名の記事を興味深く読ませて頂きました。実際に実例があったのですねぇ。ため息。 括弧なしのXSSという題材については、その後、Our Favorite XSS Filters/IDS and how to Attack Them を読んでみたところ、setterを使用しない解があることを知りました。 setterの古い記述を使っていた、Firefox専用のexploitではなく、より汎用的なベクタがあるのですね、まったく気がつきませんでした。手元で試しましたが、複数のブラウザで有効のようでした。ベクタの表記は極めて簡単でして、普通に暗記できます。以下。 location = name罠のページに誘導しておいて、そのページにおいてname属性つきのiframe要素などで脆弱な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く