The Web Robots Pages
Web Robots (also known as Web Wanderers, Crawlers, or Spiders), are programs that traverse the Web automatically. Search engines such as Google use them to index the web content, spammers use them to scan for email addresses, and they have many other uses. On this site you can learn more about web robots. About /robots.txt explains what /robots.txt is, and how to use it. The FAQ answers many frequ
JSON SQL Injection、PHPならJSONなしでもできるよ
DeNAの奥さんと、はるぷさんがJSON SQL Injectionについて公表されています。 The JSON SQL Injection Vulnerability 不正なJSONデータによるSQL Injectionへの対策について (Json.pm+SQLクエリビルダー) 上記の記事は、主にPerlスクリプトがJSONデータを受け取るシナリオで説明されています。もちろん、この組み合わせに限定したはなしではないわけで、それではPHPではどうだろうと思い調べてみました。 JSON SQL Injectionとは 以下、はるぷさんの「不正なJSONデータによる…」にしたがってJSON SQL Injectionについて説明します。 Perl向けのSQLジェネレータの一つであるSQL::Makerにおいて、以下のスクリプトを想定します。 my ($sql, @bind) = $builde
文字コードの脆弱性はこの3年間でどの程度対策されたか?
2019/01 JSUG勉強会の資料です。 この資料でDisっているのはJPAではなく、 ・何も考えずに「標準だから」というだけでJPAを選ぶ人 ・OSSに全くコントリビュートせずにフリーライドする人 です。
単純ではない、最新「クロスサイトスクリプティング」事情
単純ではない、最新「クロスサイトスクリプティング」事情：HTML5時代の「新しいセキュリティ・エチケット」（2）（1/3 ページ） 連載目次 皆さんこんにちは。ネットエージェントのはせがわようすけです。第1回目は、Webアプリケーションセキュリティの境界条件であるオリジンという概念について説明しました。 現在のWebブラウザーでは、同一オリジンのリソースは同じ保護範囲にあるものとし、オリジンを超えたアクセスについてはリソースの提供元が明示的に許可しない限りはアクセスできないという、「同一オリジンポリシー（Same-Origin Policy）」に従ってリソースを保護しています。 その保護範囲であるオリジンを超え、リソースにアクセスする攻撃の代表事例であるクロスサイトスクリプティング（XSS）について、今回、および次回の2回に分け、HTML5においてより高度化された攻撃と、その対策を説明しま
最低限おさえておくべき「プライバシーポリシー」のポイント（後編） | 良いウェブサービスを支える「利用規約」の作り方
この内容の前編を読んでおく。 個人情報を第三者に提供するときはポリシーに明記し同意を取る個人情報保護法は、取得した個人情報を第三者に提供する際には、原則として本人から同意を得ることを求めています。そのため、個人情報を第三者に提供する場合は、プライバシーポリシーにおいてその旨を明記する必要があります（もちろん、プライバシーポリシーに対してユーザーが同意することが前提となります）。 個人情報の「利用目的」については、前述のように明示すれば良いとされています。しかし、個人情報を第三者に提供することは、より本人にとってインパクトが大きいため、本人の「同意」まで要求しているのです。 この個人情報の「第三者提供」は、ユーザーが抵抗を感じやすい事項ではありますが、以下のように、意外と多くあります。 広告モデルのウェブサービスの場合で、広告出稿者にマーケティングのための参考情報として、ユーザー情報を提供す
【重要】日本中のWebサイトへの改ざん攻撃が多発中 4月から1000サイト以上が被害に | 初代編集長ブログ―安田英久
今日は、いま日本中のあらゆるWebサイトが攻撃されているという状況をお知らせします。あまり世間では大きくは騒がれていませんが、あなたの管理しているサイトもかなり危険な状態にあることを理解して対処してください。 かなり、シャレにならない状況になっています。 2013年4月以降 約1000件のWebサイト改ざんとの報告、 警視庁などが注意喚起へTV番組「ほこxたて」の「最強ハッカーvs最強セキュリティ」が少しだけ話題になっていますが、それどころじゃない状況です。今年に入ってから日本中のサイトに対する攻撃が増えており、特に4月～5月にかけて、その勢いが増しているのです。 2008年にWeb担当者を悩ませたGumblar（ガンブラー）のときと同様で、Webサイトの内容が改ざんされ、そのサイトを閲覧した人がウイルスなど悪質なプログラムを自動的にダウンロードするようになっているサイトが急激に増えている
Yahoo!知恵袋にXSS？ - yhgnの「自分に向けて書く」ブログ
2013-07-22 Yahoo!知恵袋にXSS？ <script>alert("xss");</script> これであなたもおしまいです。 - Yahoo!知恵袋 ryosuke_i_628さん「あなたが最近見たQ＆A」にXSS脆弱性があるみたいですね・・・ あー、そうみたいですね。history.jsで // タイムスタンプでソート items.sort(function(a, b) { return (a.timestump < b.timestump) ? 1 : -1; }); var html = ''; for(var i = 0; i < items.length; i++) { value = items[i]; var href = self.RD_URL + 'PAGE=' + page + '/LOC=' + loc + '/R=' + (i + 1) + '/*
もう入力値検証はセキュリティ対策として *あてにしない* ようにしよう
スタックオーバーフロー対策をする場合、関数の入口でチェックすれば大抵対策可能なんだけど、それだと対策漏れの可能性があるから、例えば、strcpyの代わりにstrncpyあるいはもっと高機能な文字列関数を使うことが当然になってきました。 これは、入口でのチェックだと漏れやすいから、脆弱性が発生するその箇所で対策するという考え方にシフトしているのだと私は考えます。 Webアプリケーションの場合も同様で、XSSやSQLインジェクションの対策は、脆弱性の発生する箇所、すなわち、HTMLの生成とか、SQLの呼び出しの時点で行います。いや、これらは「セキュリティ対策」ではなく、全ての文字を扱うために必要なエスケープ処理に過ぎないので、例がよくないですね。例えば、パストラバーサル脆弱性対処のためのファイル名の確認は、ファイルをオープンする直前（ファイル名を使う直前）に行うべきだ、という考え方です。 スタ
WordPress使いならこれだけはやっておきたい本当のセキュリティ対策10項目
どうも、ブルーです。秋ですね。 季節がめぐるごとに「WordPressがクラックされたので、セキュリティ対策について調べてみました」的なブログ記事がソーシャル上で出まわり、そのたびにWordPressを扱うデベロッパー層が「また無意味な対策がはてブされてる…」と嘆くのが恒例行事のようになっております。例えば… 「WordPressのバージョンを隠す」 「データベースのプレフィクスを変更する」 「サブディレクトリーにインストールする」 うん、気休め程度かな… 「2年以上放置されている怪しげなセキュリティ対策プラグインを入れる」 そっちのほうがこええよ！ 「サーバーのディレクトリー一覧の非表示」 それ見えちゃってるサーバー管理者では、何しても不安だよ！ とはいえ、そう思いつつも「これが決定版だ！」的な記事を書くのは勇気がいるものです。特にセキュリティ業界は怖いお兄さんが多…うわ何をするやめr
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
XSS再入門