徳丸本こと、「体系的に学ぶ 安全なWebアプリケーションの作り方」は、2011年3月の発売以降大変多くの方に読んでいただきました。ありがとうございます。 ただ、発売から既に7年が経過し、内容が古くなってきた感は否めません。たとえば、クリックジャッキングの説明はほとんどないですし、OWASP Top 10 2017で選入された安全でないデシリアライゼーションやXXEの説明もありません。なにより、Web APIやJavaScriptのセキュリティ等がほとんど書かれていないことが課題となっていました。 そこで、版元のSBクリエイティブと相談して、この度改訂することにいたしました。3月末脱稿、6月頃発売の見込みです。 改訂にあたり、以下を考えています。 Web APIとJavaScriptに関する説明を4章に追加 XHR2対応に向けてCORSの説明を3章に追加 携帯電話の章は丸ごと削除して、別の内
Intro このブログで CSP レポートの収集を開始してもうすぐ 1 年になる。 現状、対象ドメイン内で <input> は一切提供しておらず、大半が静的に生成されたページであるが、この条件でも、かなり多くのレポートが集まった。 今回は、収集した実際のレポートを例に、攻撃ではないと思われるレポートとしてどういったものが送られて来たかを中心に、その内容やレポーティングサーバ、CSP の運用に関する現時点の考察についてまとめる。 収集目的 CSP の基本は、意図しないリソースの読み込みや、Inline Script の実行を防ぐことにある。 例えば、エスケープ漏れにより XSS が発生し、悪意のある Inline Script が埋め込まれた場合でも、Inline Script を禁止するポリシーを適用したページでは、その実行はブラウザによって Violation(違反)と判断されブロックさ
はじめに 昨年、Googleから Google Cloud Platform に関するWhitePaperがいくつか公開されました。その中でGoogleのサービス内部で使われている新しいALTSというプロトコルを説明した文書「Application Layer Transport Security」は、読んでみると非常に面白く、セキュアなサービス間通信には本当に何が必要なのか、といったことを改めて深く考えさせられるものでした。物理的なマシンからサービス運用まで、ALTSがカバーする範囲は幅広い領域に渡り、あの巨大なGoogleのサービスをよくここまでまとめ上げたものだとホント感心させられます。 以前から、Googleはデータセンタ内のサービス通信までも暗号化を進めていると言われていました。それは、2013年にエドワード・スノーデンが暴露した資料が、Googleのデータセンタ内部の通信データ
「TLS暗号設定ガイドライン」は、TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするためのガイドラインです。「様々な利用上の判断材料も加味した合理的な根拠」を重視して、TLS通信での実現すべき安全性と必要となる相互接続性とのトレードオフを考慮した3つの設定基準（「高セキュリティ型」「推奨セキュリティ型」「セキュリティ例外型」）を設けており、各々の設定基準に対応して、TLSサーバで設定すべき具体的な要求設定（「遵守項目」と「推奨項目」）を決めております。 本ガイドラインは安全なウェブサイトの作り方とともに適切な暗号設定をする資料の一つとしてお使いいただけます。 なお、本ガイドラインは、暗号技術評価プロジェクトCRYPTRECで作成されました。 「TLS暗号設定ガイドライン」の内容 1章と2章は、本ガイドラインの目的やSSL/TLSについての技術的な基礎知識を
本日コーポレートサイトでお知らせした通り、Web版のメルカリにおいて一部のお客さまの個人情報が他者から閲覧できる状態になっていたことが判明しました。原因はすでに判明して修正が完了しております。また、個人情報を閲覧された可能性のあるお客さまには、メルカリ事務局より、メルカリ内の個別メッセージにてご連絡させていただきました。 お客さまの大切な個人情報をお預かりしているにも関わらず、このような事態に至り、深くお詫びを申し上げます。 本エントリでは技術的観点から詳細をお伝えさせていただきます。 2017年6月27日 CDNのキャッシュの動作について、CDNプロバイダと仕様について確認し検証を行いました。その結果一部記述に実際と異なる箇所があり、加筆修正いたしました。 概要 メルカリWeb版のコンテンツキャッシュをしているCDNのプロバイダ切り替えを行いました。 その際本来キャッシュされるべきでない
Introduction This is a simple tutorial that will teach you to configure your system to automatically install security updates. There are always some security risks involved in running software upgrades without supervision, but there are also benefits. If you believe it's important to stay up to date with the latest security patches, then you should follow this simple tutorial. There are several op
Broken Authentication and Session Management are #2 at the OWASP Top 10. Avoid rolling your own authentication unless you know exactly what you are doing. Consider using a gem such as Devise, Authlogic or Clearance. Mitigates dozens of potential vulnerabilities. Enforce a minimum password length of 8 characters or more. Mitigates brute-force attacks. Devise: set config.password_length = 8..128 in
This website uses cookies to analyze our traffic and only share that information with our analytics partners. Accept Learn the hack - Stop the attack WebGoat is a deliberately insecure application that allows interested developers just like you to test vulnerabilities commonly found in Java-based applications that use common and popular open source components. Description Web application security
Googleのクラウドは間違いなく世界最大規模のコンピュータシステムです。膨大なハードウェアとソフトウェアから構成されるこの巨大なシステムを、同社はどうやってセキュアに保っているのか。そのことを解説したホワイトペーパー「Google Infrastructure Security Design Overview」が公開されました。 ホワイトペーパーには、Googleのデータセンターを構成するデバイスの1つ1つにまで独自のセキュリティチップを組み込んで正規のデバイスかどうかを相互に認証するという物理レベルのセキュリティから、何層のものロードバランサーからの情報を集約してDos攻撃を検知すると、その通信を破棄するといったDoS対策。 そしてマシンも従業員もサービスも包括するグローバルな名前空間など、きわめて広範かつ綿密なセキュリティ施策が説明されています。 クラウドがいかに高度なセキュリティで
yapcjapan2016_lt.md 5分でわかる Perl and web security ma.la CSRFとかXSSとか CSRF: フレームワークの機能使って下さい XSS: Xslateとか自動エスケープして下さい、jsの動的生成はするな 終わり 本題 YAPCなのでPerl固有の問題について解説します。 Webアプリケーションの一般的な流れ パラメータ受け取る(フォームとかJSONとか) 何らかの処理をする レスポンスを返す(HTMLとかJSONとか) フォームやJSONを安全に受け取るには paramはscalarで受け取りましょう Why $params = { name => $r->param("name"), value => $r->param("value"), } これをやると ?name=hoge&name=fuga で壊せる。 list context
GitLab CE/EE versions 8.9, 8.10, 8.11, 8.12, and 8.13 are vulnerable to an arbitrary file read vulnerability. The vulnerability could be exploited to gain access to the application's secrets. These secrets could be used to gain command execution access on the application server. The CVSS for the vulnerability in versions 8.9, 8.10, 8.11, and 8.12 is determined to be 8.4...
The webconsole gem which ships with the Rails development server allows remote code execution via DNS Rebinding. I reported this issue to Rails on April 20th 2015. However, it may have been reported to them earlier because Homakov also found the issue independently and tweeted about it here: There are lots of dangerous interactions with localhost: I tweeted that with DNS rebinding we can RCE via R
昨日のCovert Redirect で Query 漏れるケースもある!?やOAuth 2.0 の脆弱性 (!?) “Covert Redirect” とはにあるように、OAuth 2.0 の code が漏れちゃうことも、ありえます。 漏れないためにやるべきことは、上記の記事やFacebook Login で Covert Redirect を防止するなんかでも紹介してるので、そちら読んでください。 で、今回の内容は「code が漏れたら何がまずいのか」についてです。 「code は漏れても大丈夫」説 「Covert Redirect」についての John Bradley 氏の解説（追記あり）にも、こうありましたね。 OAuth と OpenID Connect には複数の response_type があるんだけど、さきのリポートの著者は、最も一般的な response_type が
Rails developers responsible for maintaining production apps will regularly run bundler-audit to alert them to known vulnerabilities in the Ruby gems their apps depend on. Thank you to postmodern for creating and maintaining this vital tool for the Ruby community. bundler-audit is a command line tool with a database of known gem vulnerabilities. It can update its database with the latest vulnerabi
0. 簡単なSLOTH攻撃のまとめ 最初に簡単なまとめを書いておきます。長文になりそうなので、読むのが大変な方はここだけ見ておいてください。 MD5ハッシュは既に安全ではなく、証明書の署名方式での利用は停止されていたが、後方互換のためハンドシェイクデータの署名方式にRSA-MD5が今でも利用できるTLS実装が幾つか存在していた(Firefox NSS, Java等)。 先週、INRIAグループからハッシュ衝突を利用して実際にTLSを破る攻撃(SLOTH)が公開された。それを受け、いくつかの実装でRSA-MD5を完全に利用不能にする修正が行われた(CVE-2015-7575)。 SLOTHでは、SHA1やTLS、IKE、SSHに対する攻撃についても評価を行い、幾つかは全く現実的に不可能なレベルではないことが示された。MD5とSHA-1でTLSハンドシェイクの完全性を担保しているTLS1.0/
自分メモ。 追記 aws.typepad.com DDoS に関するホワイトペーパーも日本語訳されて公開されている。後ほど読みませう。 tl;dl こちらに紹介されている資料をダウロードして読んでみた。 セキュリティプロセスの概要 AWS セキュリティとコンプライアンス AWSのセキュリティについて 内容をちゃんと把握は出来ていないが、以下に雑にメモる。 感想等 読んでみて セキュリティプロセスの概要 はホワイトペーパー（全 27 ページ）でほぼ文字だったが、各 AWS リソースのセキュリティ実装について触れられていた AWS セキュリティとコンプライアンスと AWSのセキュリティについてについては上記のホワイトペーパーをわかりやすく解説するような構成になっていた ピックアップキーワード 責任分担モデル（セキュリティ共有モデル）→ AWS はインフラ部分のセキュリティに責任を持つ セキュリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
