はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
2010 年 9 月 21 日現在のツイッターのバグ(脆弱性)について
【お知らせ】 9 月 21 日午後 11 時頃、公式サイドから脆弱性が修正されたとの発表がありました。 はじめに 2010 年 9 月 21 日、ツイッターで深刻な脆弱性(ぜいじゃくせい)が発見され、被害が広がっています。これが何なのか、簡単に説明します。 JavaScript とマウスオーバーイベント まず、下のピンク色の枠内にマウスカーソルをすべらせてみてください。 この枠の中をマウスカーソルで触って! どうでしたか。「触ってくれてありがとう!」というメッセージが表示されましたね。 このように、ウェブページには簡単なプログラムを仕込むことができます。どのウェブブラウザー(皆さんがウェブを見る時に使うソフトウェア。インターネットエクスプローラーなど)でも共通で使える「JavaScript (ジャバスクリプト)」という言語が一般的に使われています。 今回は、ページ上のある部分にマウスカーソ
Re:htmlspecialcharsに関する残念なお知らせ - 平々毎々（アーカイブ）
<追記 date="2009/10/10"> 岩本さんはレポートを2つ上げていたのだが http://bugs.php.net/bug.php?id=49785 http://bugs.php.net/bug.php?id=49814 1つ目の方で対応してもらえたようです。よかった。 私はPHPはぜんぜん詳しくないし、OSSへのバグレポートの経験は1回しかないので、はずしているかもしれない。 htmlspecialcharsに関する残念なお知らせ - 岩本隆史の日記帳（アーカイブ） 外国語ならなおさら、できる限りのことをしないと伝わらない – 秋元 こんな感じの内容だったらよかったのかな？せっかくいろんな人が検証したりしてたのに無視されるのももったいない。 PHPのhtmlspecialchars関数について、UTF-8以外の文字エンコーディングでは妥当性チェックが不充分であり、場合によっ
TechCrunch | Startup and Technology News
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
ツッコミ hideden (2009-08-06 12:45) - 徳丸浩の日記 - i-mode2.0セキュリティの検討 - 携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性
SQLインジェクション対策はおすみですか? 開発開始時点からのコンサルティングから、公開済みWebサイトの脆弱性検査、 脆弱性発見後の適切な対策まで ●携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性 このエントリでは、携帯電話のブラウザに搭載されたJavaScriptと、WebサイトのXSSの組み合わせにより、いわゆる「かんたんログイン」に対する不正ログインの可能性について検討する。 5月28にはてなダイアリーに書いた日記「i-mode2.0は前途多難」にて、今年のNTTドコモの夏モデルP-07AにてJavaScript機能が利用停止されたことを指摘した。同日付のNTTドコモ社のリリースによると、「ソフトウェア更新に伴い、高度化した機能の一部をご利用いただけなくなっていますが、再びご利用いただけるよう速やかに対処いたします」とあったが、それ以
文字コードのセキュリティ問題はどう対策すべきか: U+00A5を用いたXSSの可能性 - 徳丸浩の日記(2009-03-11)
_U+00A5を用いたXSSの可能性 前回の日記では、昨年のBlack Hat Japanにおける長谷川陽介氏の講演に「趣味と実益の文字コード攻撃(講演資料)」に刺激される形で、Unicodeの円記号U+00A5によるSQLインジェクションの可能性について指摘した。 はせがわ氏の元資料ではパストラバーサルの可能性を指摘しておられるので、残る脆弱性パターンとしてクロスサイト・スクリプティング(XSS)の可能性があるかどうかがずっと気になっていた。独自の調査により、XSS攻撃の起点となる「<」や「"」、「'」などについて「多対一の変換」がされる文字を探してきたが、現実的なWebアプリケーションで出現しそうな組み合わせは見つけられていない。 一方、U+00A5が処理系によっては0x5C「\」に変換されることに起因してXSSが発生する可能性はある。JavaScriptがからむ場合がそれだ。しかし、
ITproのセキュリティ検定がヤバイ | 水無月ばけらのえび日記
更新: 2008年11月7日1時55分頃 こんなのがあったのですね。「ITpro EXPO検定---全11分野で，あなたのIT理解度はいかに？ (itpro.nikkeibp.co.jp)」。 セキュリティ検定の解説もあったので見てみましたが、超難問が3問ほどあったので、独自に解説してみます。 Webブラウザを狙うクロスサイト・スクリプティングは，どのような問題点によって起こるでしょうか。 A） クライアントOSの弱点（ぜい弱性） B） Webブラウザを使うユーザーの油断 C） Webブラウザの弱点（ぜい弱性） D） Webサーバーの弱点（ぜい弱性） 以上、セキュリティ検定の解説【問題2】 より 「WebサーバやWebブラウザにもクロスサイトスクリプティング脆弱性がある」という知識を問う問題ですね。XSSというと普通はWebアプリケーションの問題ですが、WebブラウザやWebサーバに問題が
個人だから甘いのかな - ぼくはまちちゃん！
あらあら予告inがXSSやられちゃったらしいですね！ 使い古された手法？ いまどきエスケープ処理すらしてなくてダサい？ 関連の記事に対して、はてなブックマークでも色々言われていたり、 http://b.hatena.ne.jp/t/%E4%BA%88%E5%91%8A.in?threshold=1 ニュースサイトでも、こんな煽り記事を書かれていたりするけれど… 今回の件についてIT企業に勤めるエンジニアに聞いてみると、 「これは初歩中の初歩。XSSコード書いた方も10分も掛かってないよ。それを事前に対策してなかった予告inにはもっとビックリだけど、、、素人なの？」 と語る。 予告inセキュリティ脆弱性を狙ったコード!? 「予告in開発者は素人」 http://news.livedoor.com/article/detail/3759632/ それってどうだろうね。 GoogleやAmazo
【ハウツー】もう試しましたか? Googleの脆弱性発見ツール「ratproxy」 (1) XSS問題などを検出可能 | エンタープライズ | マイコミジャーナル
Webアプリケーション開発者にとって切っても切れない問題――それがセキュリティ対策だ。日増しに複雑になっていく要件・機能に対する脆弱性検査に悲鳴をあげているデベロッパ/テスターも多いことだろう。そのような中、あのGoogleが、社内でも活用している脆弱性発見ツールをオープンソース化して公開した。同ツールは脆弱性検査の新しい決め手となるか。以下、基本的な使い方や主要機能について紹介していこう。 Google社内で現役の脆弱性検知ツール - ratproxy Googleは1日(米国時間)、Webアプリケーションのセキュリティ監査を実施するツール「ratproxy」をリリースした。ratproxyはプロキシサーバとして動作するオープンソースソフトウェア。同ソフトウェアを経由してWebアプリケーションを操作することで、XSS(Cross Site Scripting)問題や不適切なXSRF(Cr
クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記
昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS
もいちどイチから！ HTTP基礎訓練中 第1回 XSSは知ってても、それだけじゃ困ります？ ― ＠IT
分かってるつもりではあるけれど…… クウはベンチャー企業で働くWebアプリケーションのエンジニア。でもそこは小さなベンチャー企業、セキュリティのことは分かっていながらも、動くものを納品するので精いっぱい……。今日は納品のため、客先でミーティングに参加していた。そしてお客様から受けた指摘は、こんな一言だった。 お客さん 「……で、このWebアプリケーション、セキュリティは大丈夫なんだよね？」 クウ 「は、はいっ！ もちろんです！」 お客さん 「じゃあ、これからもよろしく頼むよ」 クウ、ユウヤ 「よろしくお願いしますっ！」 無事、お客さんとのミーティングを終えたクウとユウヤの2人は、近くの喫茶店で一息いれることにした。 クウ 「最近はセキュリティのことを聞かれることがかなり増えてきましたねぇ」 ユウヤ 「ああ、そうだね。営業の段階から『セキュリティはどう担保されているんだ？』なーんてことをいわ
まだまだあるクロスサイト・スクリプティング攻撃法
前回はクロスサイト・スクリプティングのぜい弱性を突く攻撃の対策としてのHTMLエンコードの有効性を述べた。ただ，HTMLエンコードだけではクロスサイト・スクリプティング攻撃を完全に防御することはできない。そこで今回は，HTMLエンコードで対処できないタイプのクロスサイト・スクリプティング攻撃の手口と，その対策について解説する。 HTMLエンコードで対処できない攻撃には，次のようなものがある。 タグ文字の入力を許容している場合（Webメール，ブログなど） CSS（カスケーディング・スタイルシート）の入力を許容している場合（ブログなど） 文字コードを明示していないケースでUTF-7文字コードによるクロスサイト・スクリプティング <SCRIPT>の内容を動的に生成している場合 AタグなどのURLを動的に生成している場合注） 以下では，HTMLタグやCSSの入力を許容している場合と，文字コードを明
対策遅らせるHTMLエンコーディングの「神話」
クロスサイト・スクリプティングという言葉は元々，WebアプリケーションのHTMLエンコード漏れなどを利用することによって第三者にJavaScriptを実行させる手法を指す。広義では，HTMLのエンコードによる画面改変などを含むこともある。 前回述べたように，クロスサイト・スクリプティングのぜい弱性はWebアプリケーションに見付かるぜい弱性の半分以上を占める。数年前から指摘されているにもかかわらず，一向になくならない。その理由として，クロスサイト・スクリプティング対策あるいはHTMLエンコード注1）に対する「神話」があり，正しい対策の普及を遅らせているように思う。その「神話」の数々について説明しよう。 注1）実体参照（entity reference）というのが正式だが，あまり普及していない用語なので，HTMLエンコードという用語を用いる 「すべからくHTMLエンコードすべし」が鉄則 HTM
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
