続々、Publickeyが受けたDDoS攻撃。DDoS対策に効果を発揮した設定紹介編
3月12日火曜日に始まったPublickeyへのDDoS攻撃に対して、これまでサーバの強化、Cloudflareの導入とDDoS対策のための設定を行ってきました。 その結果、3月24日日曜日の夜に始まり3月27日水曜日の朝まで3日間連続で続いたDDoS攻撃のあいだもWebサイトの閲覧と記事更新などを問題なく行える状態となり、DDoS攻撃がWebサイトの運営の大きな障害ではなくなりました。 ちなみにそれ以後DDoS攻撃は止んでいますが、今後はいつDDoS攻撃を受けてもWebサイトの運営に支障がでることはなくなったと考えられます。この記事では結局どのような対策を行ったのか、実際に効果を発揮したDDoS対策を紹介していきます。 これまでの経緯は下記の記事をご参照ください。 Publickeyが受けたDoS攻撃、これまでの経緯と対策まとめ 続、Publickeyが受けたDoS攻撃、これまでの経緯と
続、Publickeyが受けたDoS攻撃、これまでの経緯と対策まとめ
先週の火曜日、3月12日に始まったPublickeyへのDDoS攻撃は今週日曜日、3月18日日曜日の早朝を最後に収まったようです。この記事執筆時点でPublickeyのサーバは平常に戻っています。 この間、読者や広告を掲載いただいているお客様や代理店様にご不便やご心配をおかけし申し訳ありませんでした。 DoS攻撃とは、大量のトラフィックをWebサーバなどに浴びせることでサーバを応答不能にしてしまう攻撃のことです。 前回の報告「Publickeyが受けたDoS攻撃、これまでの経緯と対策まとめ」の後、さらにいくつか対策を講じましたので、この記事では前回の報告以後の経緯と講じた対策を記したいと思います。 また、前回の報告では「DoS攻撃」と書きましたが、その後Publickeyのサーバをホスティングしているさくらインターネットのサポート担当の方から、今回の攻撃は分散した箇所から攻撃を受けていると
安全なウェブサイトの作り方~失敗例~ - goruchan’s blog
安全なウェブサイトの作り方を読んだので、理解した内容を自分なりにまとめておきます。資料 上記は3章構成になっていてそれぞれ長めの内容なので、ここでは3章の『失敗例』について、Ruby on Rails ではどうするかについてをまとめます。 SQL インジェクション OS コマンドインジェクション パス名パラメータの未チェック例（ディレクトリトラバーサル） 不適切なセッション管理例（セッション ID の推測） クロスサイト・スクリプティングの例（エスケープ処理） CSRFの例 HTTP ヘッダ・インジェクションの例 メールヘッダ・インジェクションの例 参考 SQL インジェクション 参考資料内の SQL インジェクション例を見て、Ruby on Rails ではどのように対策できるかを確認しました。 例えば、下記ような $uid, $pass をユーザ入力とし、SQL 文を動的に生成する場合
IPAのサイトリニューアルに総ツッコミ 多くの旧ページが「404」、リダイレクトせず 「なぜこんな雑に」
情報処理推進機構（IPA）の公式Webサイトリニューアルについて、Twitter上で批判の声が上がっている。新URLへのリダイレクト設定がなく既存のリンクを開いても「404 Not Found」になっているとの報告が相次いでいる他、RSSがなくなって困るというユーザーもいる。 IPAが新サイトを公開したのは3月31日。「ユーザーがコンテンツを探しやすいよう導線を改善した」「スマートフォンやタブレットでの閲覧を想定してマルチデバイス対応をした」としている。 リニューアルによりURLの変更もあったが、新ページへのリダイレクト設定がなく、既存のリンクを開いてもコンテンツが表示されないケースが多発している。 例えばGoogle検索で「情報セキュリティ白書2021」を検索すると、検索結果トップに該当ページが表示されるが、リンクを開いても「お探しのページ・ファイルが見つかりませんでした」とのみ表示され
入力中の個人情報が“送信ボタンを押す前に”収集されている問題 約10万のWebサイトを調査
Innovative Tech： このコーナーでは、テクノロジーの最新研究を紹介するWebメディア「Seamless」を主宰する山下裕毅氏が執筆。新規性の高い科学論文を山下氏がピックアップし、解説する。 ベルギーのKU Leuven、オランダのRadboud University、スイスのUniversity of Lausanneによる研究チームが発表した「Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission」は、まだ送信していないのにもかかわらず、オンラインフォームで入力した個人情報（今回は電子メールアドレスとパスワード）が打ち込んだだけで収集されている問題を調査した論文だ。 サインインやサービスへの登録、ニュースレターの購読など、さまざまな理由でオンラインフォームに個人情報を入力す
ブラウザーの中に「偽ブラウザー」を表示、URLを確認しても防げないフィッシング
だがWebブラウザーのセキュリティーは年々強化され、こういった手口はほとんど使えなくなった。このため前述のようにアドレスバーの表示を確認することが、偽サイトに誘導されないための有効な対策になっている。 今回「mr.d0x」を名乗るセキュリティー研究者が警鐘を鳴らすのは、Webブラウザーが表示するポップアップウインドウ（Webブラウザーウインドウ）である。Webブラウザーのアドレスバーではなく、ポップアップウインドウのアドレスバーを偽装する。アドレスバー付きのポップアップウインドウは「Webブラウザーが表示するWebブラウザー」といえるので、この手口はBrowser In The Browser（BITB）攻撃と名付けられた。 BITB攻撃の主な対象となるのは、ソーシャルログインのログイン画面である。ソーシャルログインとは、SNSのアカウントで別のWebサービスにログインできるようにする仕組
Web開発者はもっと「安全なウェブサイトの作り方」を読むべき - Flatt Security Blog
画像出典: https://www.ipa.go.jp/files/000017316.pdf こんにちは。株式会社Flatt Security セキュリティエンジニアの奥山です。 本稿では、独立行政法人 情報処理推進機構(以下、IPA)が公開している資料「安全なウェブサイトの作り方」を紹介します。 「安全なウェブサイトの作り方」は、無料で公開されているにも関わらず、Webセキュリティを学ぶ上で非常に有用な資料です。これからWeb開発やセキュリティを勉強したいと考えている方はもちろん、まだ読んだことのない開発者の方々にも、ぜひ一度目を通していただけたらと思います。 一方、「安全なウェブサイトの作り方」では、一部にモダンなアプリケーションには最適化されていない情報や対象としていない範囲が存在します。それらについても本記事で一部、触れていきたいと考えていますので、資料を読む際の参考にしていただ
7594591200220899443 on Twitter: "ひえーFacebook、Aタグの上でマウス押下した瞬間にhref書き換えてんのか！で次の瞬間マウスクリックするとその書き変わったURLを踏む https://t.co/7r8ZccLLnk"
ひえーFacebook、Aタグの上でマウス押下した瞬間にhref書き換えてんのか！で次の瞬間マウスクリックするとその書き変わったURLを踏む https://t.co/7r8ZccLLnk
高木浩光＠自宅の日記 - 「安全なウェブサイトの作り方」HTML版にリンクジュースを注ぎ込む
■ 「安全なウェブサイトの作り方」HTML版にリンクジュースを注ぎ込む IPAの「安全なウェブサイトの作り方」（改定第7版2015年、初版2006年）のHTML版が出ている。項目別にページが作られている。 1.1 SQLインジェクション 1.2 OSコマンド・インジェクション 1.3 パス名パラメータの未チェック／ディレクトリ・トラバーサル 1.4 セッション管理の不備 1.5 クロスサイト・スクリプティング 1.6 CSRF（クロスサイト・リクエスト・フォージェリ） 1.7 HTTPヘッダ・インジェクション 1.8 メールヘッダ・インジェクション 1.9 クリックジャッキング 1.10 バッファオーバーフロー 1.11 アクセス制御や認可制御の欠落 というのも、4年前にWELQ問題が火を噴いたのと同様に、キーワードWeb検索からの流入を当て込む「いかがでしたか系」の乱造記事のSEO汚染の
旧ドメインはご利用にならないようご注意ください。 ｜ イオンシネマ
【重要なお知らせ（ご注意）】当社HPへアクセスされる場合、旧ドメインはご利用にならないようご注意ください。 （１）イオンエンターテイメント株式会社（以下「当社」といいます）は、商号の変更（会社の統合）に伴い、2013年7月1日に「http://www.warnermycal.com/」という旧ドメインから「http://www.aeoncinema.com/」という現在のドメインへ切り替えを行いました。 このような状況下で、現在、当社の旧ドメイン「http://www.warnermycal.com/」にアクセスされた場合、意図せぬサイトへ遷移するという事例が報告されております。 （２）旧ドメインについては、現在、当社において管理・運用を行っておらず、当社とは無関係の第三者が取得・管理しており、前記遷移先のサイトについても当社とは無関係です。 そのため、旧ドメインへアクセスすることにより、
Heartbleed脆弱性と、その背後にあるWebアプリケーションアーキテクチャの一般的欠陥について
■Heartbleedのリスクと善後策 Heartbleedは、攻撃者が一定の条件を満たすOpenSSLが動作しているサーバの、任意位置のメモリを外部から読み出すことができてしまうという脆弱性です。具体的には、以下のようなリスクが想定されています。 秘密鍵の漏洩による、偽サイトの出現（あるいは中間者攻撃） 秘密鍵の漏洩により、（過去のものを含む）パケットキャプチャの解読 サーバの同一プロセスが行った処理に関連する（他のユーザーのパスワードやセッションキーを含む）データの漏洩 漏洩した秘密鍵を用いた攻撃には、ユーザーを偽サイトへ誘導できたり、パケットの経由点を管理しているなどの、経路上の要件が必要になります。他のユーザーのデータの漏洩については、経路上の要件は不要な一方、攻撃の実施に近いタイミングでサーバにアクセスしたユーザーのデータしか漏れない、という違いがあります。 どこまで対策を施すべ
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
PHPのイタい入門書を読んでAjaxのXSSについて検討した(1) - ockeghem's blog
このエントリでは、あるPHPの入門書を題材として、Ajaxアプリケーションの脆弱性について検討します。全3回となる予定です。 このエントリを書いたきっかけ twitterからタレコミをちょうだいして、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeという本を読みました。所感は以下の通りです。 タレコミ氏の主張のように、本書はセキュリティを一切考慮していない 主な脆弱性は、XSS、SQLインジェクション、任意のサーバーサイド・スクリプト実行（アップロード経由）、メールヘッダインジェクション等 脆弱性以前の問題としてサンプルスクリプトの品質が低い。デバッグしないと動かないスクリプトが多数あった 上記に関連して、流用元のソースやデバッグ用のalertなどがコメントとして残っていて痛々しい 今時この水準はないわーと思いました。以前
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
