個人的に「Webサービスの公開前チェックリスト」を作っていたのですが、けっこう育ってきたので公開します。このリストは、過去に自分がミスしたときや、情報収集する中で「明日は我が身…」と思ったときなどに個人的にメモしてきたものをまとめた内容になります。 セキュリティ 認証に関わるCookieの属性 HttpOnly属性が設定されていること XSSの緩和策 SameSite属性がLaxもしくはStrictになっていること 主にCSRF対策のため。Laxの場合、GETリクエストで更新処理を行っているエンドポイントがないか合わせて確認 Secure属性が設定されていること HTTPS通信でのみCookieが送られるように Domain属性が適切に設定されていること サブドメインにもCookieが送られる設定の場合、他のサブドメインのサイトに脆弱性があるとそこからインシデントに繋がるリスクを理解してお
7月の初旬、朝8時。 25トンのコンテナを積んだトレーラーが、いつものように搬入先の名古屋港を訪れた。 しかし、港の入り口のゲートは閉じたまま。 8時間待ったが、この日、開くことはなかった。 運転手の男性がこの仕事に就いてから7年、全く初めてのことだった。 別の輸送会社は、30年近く前の阪神・淡路大震災以来の「決断」を迫られた。 コンテナの搬入先を別の港へと切り替えるため50社の取引先に頭を下げ、手続きに忙殺された。 貿易総額は年間およそ21兆円。 取り扱い貨物量で日本一の名古屋港。 海の物流の大動脈を混乱に陥れたサイバー攻撃、その深層に迫る。 7月4日。 名古屋市のトレーラー運転手、安井隆師さんは、新人とコンテナの搬入のため、名古屋港に向かっていた。 受付開始前の午前8時ごろに到着。 ゲートには、すでに多くのトレーラーが列をなしていた。 この仕事について7年の安井さんにとって、見慣れた風
RFC 6749 (The OAuth 2.0 Authorization Framework) で定義されている 4 つの認可フロー、および、リフレッシュトークンを用いてアクセストークンの再発行を受けるフローの図解及び動画です。動画は YouTube へのリンクとなっています。 English version: Diagrams And Movies Of All The OAuth 2.0 Flows 追記 (2019-07-02) 認可決定エンドポイントからクライアントに認可コードやアクセストークンを渡す方法については、別記事『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』で解説していますので、ご参照ください。 追記（2020-03-20） この記事の内容を含む、筆者本人による『OAuth & OIDC 入門編』解説動画を公開しました！ 1. 認可コードフロー RF
DDoS攻撃、売ります。PSNとXbox Liveをハックした組織が攻撃を商品化2015.01.03 13:00 福田ミホ ある意味ストレステストとな。 先週、クリスマスに合わせたかのようにLizard Squadなるハッカー集団がPlayStation NetworkとXbox Liveを大規模なDDoS攻撃でダウンさせました。そのLizard Squadが今、DDoS攻撃を商品化して、お金さえ払えば誰でも利用できるようにしました。 先日のハッキング攻撃は、クリスマスに手に入れた新しいゲームをプレイしたいゲーマーたちの楽しみを奪って混乱に陥れました。でもこのタイミングで商品を発表するということは、Lizard Squadは単に騒ぎを起こしたかったわけじゃなくて、注目を集めてDDoS攻撃サービスのプロモーションに利用しようとしていたのかも？と思ってしまいます。 彼らの新サービス｢Lizar
こんにちはこんにちは！！ 先日、Twitterで声をかけてもらって、 第一回 Port801 セキュリティ勉強会っていうのに参加してきたよ！！ (↑pw: security) そこで、すこし喋った時のビデオを頂いたので、もったいないので公開しちゃいますね！ プレゼンだとかそういうの慣れてなくて、ぐだぐだな感じだけど、 よかったら何かの参考にしたり、晩ご飯のおかずにしてください＞＜ Port801 セキュリティ勉強会 - Hamachiya2 その1 (http編) Port801 セキュリティ勉強会 - Hamachiya2 その2 (CSRF編1) Port801 セキュリティ勉強会 - Hamachiya2 その3 (CSRF編2) Port801 セキュリティ勉強会 - Hamachiya2 その4 (XSS編1) Port801 セキュリティ勉強会 - Hamachiya2 その5
西村誠一 @khb02323 ↓昨日、今日はじまった話でもなくて、ここ数年来続いてる話だと思うのですが、最近の偽装メールは「あまりに巧妙」なので、うっかりするとそれなりにＩＴリテラシーある人でも簡単に騙されますよ？・・・という話です。（今回、私は詳細に確認する迄本物か偽物か判別できませんでした） 2016-08-04 13:28:49 西村誠一 @khb02323 ↓私は結構パソコンでMMORPGとか色んなゲームをやる方で「ハンゲーム」のアカウントも持っていました （※）ただ、「ハンゲーム」のゲームは半年～数年やってなかったので放置状態ではありました 2016-08-04 13:28:55 西村誠一 @khb02323 ↓ゲームや銀行などで「偽装メール」、「詐称メール」は日常的に多いと思うんですが、今日、私の所に「ハンゲーム」から「ご登録パスワード変更完了のお知らせ」というシステム自動送信
インターネットでどんなサイトを閲覧したかがすべて記録される。初めて訪れたサイトなのに「あなたにはこんな商品がおすすめ」と宣伝される――。そんなことを可能にする技術の利用に、総務省がゴーサインを出した。ネット接続業者（プロバイダー）側で、情報を丸ごと読み取る技術を広告に使う手法だ。だが、個人の行動記録が丸裸にされて本人の思わぬ形で流出してしまう危険もある。業者は今後、流出を防ぐ指針作りに入る。 この技術は「ディープ・パケット・インスペクション（ＤＰＩ）」。プロバイダーのコンピューター（サーバー）に専用の機械を接続し、利用者がサーバーとの間でやりとりする情報を読み取る。どんなサイトを閲覧し、何を買ったか、どんな言葉で検索をかけたかといった情報を分析し、利用者の趣味や志向に応じた広告を配信する。 ＤＰＩは従来技術に比べてより多くのデータを集められるため、こうした「行動ターゲティング広告」に利
脆弱性の見つけ方（初心者向け脆弱性検査入門）
WEB系の情報セキュリティ関連の学習メモです。メモなので他情報のポインタだけ、とかの卑怯な記事もあります。 ※2020.9 注記:本ブログの解説記事は内容が古くなっております。OWASP ZAPなどのソフトウェアの解説は現行バージョンの仕様から乖離している可能性があります。 EC-CUBEで脆弱性を見つけたり、mixiの脆弱性報告制度で成果を挙げたりしたせいか、「どうやって脆弱性を見つけてるんですか？」という質問をされることが時折あり、一応手順は説明するのですが、いつも口頭で細かくは説明できなくて申し訳ないので、自分のやり方をまとめてこのブログにアップしておきます。 標準的な脆弱性検査のやり方しか説明していないので、脆弱性検査のやり方を既に把握している人が読んでも得るものは少ないのではないかと思います。今回は脆弱性検査に興味があるが何をどうしたらいいか分からないような初心者向けコンテンツで
前回はクロスサイト・スクリプティングのぜい弱性を突く攻撃の対策としてのHTMLエンコードの有効性を述べた。ただ，HTMLエンコードだけではクロスサイト・スクリプティング攻撃を完全に防御することはできない。そこで今回は，HTMLエンコードで対処できないタイプのクロスサイト・スクリプティング攻撃の手口と，その対策について解説する。 HTMLエンコードで対処できない攻撃には，次のようなものがある。 タグ文字の入力を許容している場合（Webメール，ブログなど） CSS（カスケーディング・スタイルシート）の入力を許容している場合（ブログなど） 文字コードを明示していないケースでUTF-7文字コードによるクロスサイト・スクリプティング <SCRIPT>の内容を動的に生成している場合 AタグなどのURLを動的に生成している場合注） 以下では，HTMLタグやCSSの入力を許容している場合と，文字コードを明
Insecamというおかしなサイトが話題。世界中の無防備なWebカメラを覗き見ることができる。 メニューから「メーカー」「国」「場所」を選べる仕様 http://www.insecam.org/ （自己責任で） 日本ではPanasonic製のカメラが覗き見られているもよう。中には銭湯の脱衣所などもあり、セキュリティー意識の低さが物議に。 Insecamというおかしなサイトが、世界中の無防備なWebカメラ73000台を表示できる、と豪語している。 その多くはCCTVやシンプルなIPカメラだが、それらに共通しているのは、一般的にアクセス可能なネットワークポートへストリーミングされていることと、デフォルトのパスワードをそのまま使っていることだ。だから誰でも、Webをクロールするロボットなどを使って、単純に”admin/admin”とタイプし、そのストリームにアクセスできる。 わざわざ弱いパスワー
apache や nginx の設定をしたことがあれば以下の様な行を見たことがある人も多いのではないでしょうか。(※ 下記は nginx の設定。apache の場合は SSLCipherSuite です。) ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5; これが暗号スイートを指定している箇所です。そしてこの部分、わけのわからない文字列の羅列なのですごく取っつきにくくて何を指定したらいいかわからないので、コピペしてしまう人も多いんじゃないでしょうか。かくいう私も数年前に趣味で TLS 対応の Web サービスを作った時はコピペで済ませていました。この暗号スイートは、以下のような OpenSSL のコマンドを使って対応している一覧を見ることができます。 $ openssl ciphers -v AES128-SH
In some of the feedback I have gotten on the openID Connect spec, the statement is made that Connect is too complicated. That OAuth 2.0 is all you need to do authentication. Many point to Identity Pro… 英語読みたくないという人のために簡単に解説すると… OAuth 2.0 の implicit flow を使って「認証」をしようとすると、とっても大きな穴が開きます。 カット＆ペーストアタックが可能だからです。 OAuth 認証？は、図１のような流れになります。 図１ OAuth 認証？の流れ 一見、問題なさそうに見えます。しかし、それはすべてのサイトが「良いサイト」ならばです。 Site_A
OWASPコミュニティのドキュメントに関するスピーチにはじまり、OWASPコミュニティの国際カンファレンスのご紹介、標準化団体における活動の共有や、企業におけるOWASPコミュニティの成果物の活用事例の共有など、多岐ジャンルにわたるミーティングとなりました。また、クロージングセッションにおいて、Chapter Leaderの岡田さんからThe OWASP Foundationの年次報告書について紹介がありました。 本記事では、今回のミーティングでのそれぞれのスピーチの内容について、ご紹介したいと思います。 図1：会場の様子。おしゃれなセミナールームをご提供いただきました。 Webアプリケーションセキュリティ要件書プロジェクト近況報告 発表概要 上野さんからは、ミーティング当日にリリースされた「Webシステム／Webアプリケーションセキュリティ要件書 2.0」について紹介いただきました。なお
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
