令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
[安全なAWSセキュリティ運用ナレッジ2022]セキュアアカウントの使い方 | DevelopersIO
AWS環境をセキュアにセットアップする方法と、その運用方法を詳細に紹介します。秘伝のタレである具体的な設定も書いてます。みんな真似していいよ！ こんにちは、臼田です。 みなさん、安全にAWS使えていますか？(挨拶 今日は全てのAWSユーザーが安全にAWSを活用し、セキュアに運用できるようにナレッジを大量にダンプしたいと思います。 弊社サービスに関連させて書く部分もありますが、基本的にどのようなAWS環境でも適用できると思います。 ちょっと長い背景 クラスメソッドでは長いこと様々なAWSを利用するお客様を支援しています。私は特にセキュリティ周りについて支援させていただくことが多く、最近はAWSのセキュリティサービスが充実していることから、これらの初期導入や運用設計、あるいはインシデント対応やその後の組織としてのセキュリティ体制づくりなどいろんな関わり方をしてきました。 どのようにセキュリティ
![[安全なAWSセキュリティ運用ナレッジ2022]セキュアアカウントの使い方 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/75550513d830c21b153b85859fb4fdabd295d23d/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2022%2F08%2Fsecurity-identity_Compliance.png)
Webサービスにおけるログイン機能の仕様とセキュリティ観点 - Flatt Security Blog
はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上 @0x003f です。 本稿では、Webアプリケーション上で実装される「ログイン機能」の実装パターンをいくつか示し、その「仕様の中で起きうる脆弱性」とその対策について解説していきます。 「ログイン機能」はToB、ToC問わず多くのWebアプリケーションで実装されている機能で、XSSやSQL Injection、Session Fixationといったような典型的な脆弱性の観点については、なんらかの解説を見たことのある方も多いと思います。 しかし、「仕様の脆弱性」というのはあまり多く語られていない印象です。今回はそのようなタイプの脆弱性についての解説を行います。なお、IDaaSを用いずに自前でログイン機能を実装しているケースを複数パターン想定しています。 はじめに ログイン機能の仕様パターンとセキュリティ
SSRF対策としてAmazonから発表されたIMDSv2の効果と限界
サマリ Capital OneからのSSRF攻撃による大規模な情報漏えい等をうけて、Amazonはインスタンスメタデータに対する保護策としてInstance Metadata Service (IMDSv2) を発表した。本稿では、IMDSv2が生まれた背景、使い方、効果、限界を説明した上で、SSRF対策におけるIMDSv2の位置づけについて説明する。 SSRFとは SSRFは、下図のように「外部から直接アクセスできないエンドポイント」に対して、公開サーバーなどを踏み台としてアクセスする攻撃方法です。SSRF(Server Side Request Forgery)の詳細については過去記事「SSRF(Server Side Request Forgery)徹底入門」を参照ください。 最終的な攻撃目標は多様ですが、近年問題になっているのが、クラウドサービスのインスタンス・メタデータを取得する
SMSで送信元を偽装したメッセージを送る
送信元表記が送信者IDのケース SMSのメッセージを受信した際に表示される送信元には、電話番号の代わりに任意の英数字も表記できる。この英数字の送信元表記を「送信者ID（Sender ID）」という。JC3の図では 通信事業者Ａ が送信者IDに当たる。 なお送信者IDの利用可否は受信側の通信事業者の対応状況によって異なる。Twilioの販売パートナーであるKWCの説明によると、日本国内ではNTT DOCOMOとSoftBankが送信者IDに対応し、KDDIは対応していないとのこと²。私はKDDIの回線を所有していないため、受信側がKDDIの電話番号を使用している場合の挙動は検証できていない。 まずはiOSの公式メッセージアプリに届いていたAmazonからのメッセージのスレッドで偽装を試みる。送信者IDは Amazon となっているため、TwilioでSMSを送信する際のFromの値に Ama
さよならCSRF(?) 2017
はじめに 2017年、ついにOWASP Top 10が更新されました。筆者が一番印象的だったのは「Top 10にCSRFが入っていない」ということです。 なぜCSRFが圏外になってしまったのかは4ページのリリースノートで軽く説明されています。「retired, but not forgotten」つまり「引退したね...でも君の事は忘れてないよ」という感じでしょうか。全米がCSRFのために泣きそうです。 それはさておき、具体的には「as many frameworks include CSRF defenses, it was found in only 5% of applications.」という部分が引退理由だと思われます。「多くのフレームワークがCSRF対策を備えた結果、5%のアプリケーションにしかCSRFは見つからなかった」というのが引退の理由です。 この理由を読むと、「というこ
このWeb APIってCSRF対策出来てますか？って質問にこたえよう - Qiita
前文 時々、このWeb APIってCSRF対策出来てますか？とか そのCSRF対策ってなんで安全なんですか？とか、そういう質問を友人・知人・同僚から受けます。 その質問に対して、都度回答をしているのですが、改めて記事としてまとめようかな、というのがこの記事です。 もし私の認識に穴・誤りがありましたら、ぜひ指摘お願いします。 前提事項 この記事中では、CSRF対策のみにフォーカスします。 そのため、以下はスコープ外です(無駄な議論回避のための前提事項です)。 セキュリティに銀の弾丸などないので、複数の脆弱性対策を組み合わせて、安全に行きましょう。 XSS脆弱性により、CSRFが可能である ブラウザの脆弱性により、CSRFが可能である XXXの脆弱性により、CSRFが可能である 前提知識 CSRF対策について語る上で必要な知識はいくつかありますが、この記事では以下の知識を前提に扱います。 ご存
暗号技術勉強メモ - Qiita
JCA (Java Cryptography Architecture) を学ぶための前提知識として、暗号技術の基本的なところを勉強したときのメモ。 JCA の使い方についてはこちら。 用語 暗号について説明する際に利用される用語について、先に整理しておく。 平文 暗号化されていないメッセージのこと。 暗号化 平文に暗号処理を施して、第三者から内容がわからないようにすること。 暗号化後のメッセージを暗号文と呼ぶ。 復号 暗号文を元の平文に戻す処理のこと。 「復号化」というと怒られる。 アリスとボブ 暗号について説明するときに慣例的に使用される仮の名前。 アルファベットの A, B, C... の順番で名前が考えられており、 Alice, Bob, Carol(もしくは Charlie)... のような感じになっている。 名前ごとに役割が決まっていて、アリスは送信者、ボブは受信者、キャロルは
リンクを作る時の target="_blank" の危険性 - 隙あらば寝る
html で リンクを新しいタブ(やウィンドウ)で開かせたい場合、target="_blank" を指定するが、 この使い方には落とし穴があるらしい。 www.jitbit.com リンクを開いた先の javascript から、開いた元のページを操作できてしまうとのこと。 気になったので確認してみた。 悪用のパターン insecure.html が最初に開くページで、ここに target="_blank" なリンクがある。 このリンクを押すと new_window.html を新しいタブで開く。 この new_window.html に javascript が仕込まれており、元ページを操作されるという話。 具体的には window.opener.location="./evil.html" と実行すると、元タブは evil.html に遷移する。 実際試してみたのが ここ。 リンクを開
JWT形式を採用したChatWorkのアクセストークンについて - ChatWork Creator's Note
JWTを使うことは難しい？ こんにちは、かとじゅん(@j5ik2o)です。最近、JWTに関する以下のブログが話題です*1。 どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ - co3k.org このブログで言及されているのは、JWTをセッションの保存先に選ぶことで「何が問題なの？」に書かれているリスクがあるよ、という話*2。確かにいくつか検討することがありますね。 auth0.hatenablog.com auth0の中の人？よくわからないけど、反論的なブログエントリが公開されています。この記事では、指摘の問題が起こらないように設計するのはあたり前では？という意見みたいです。まぁごもっともではないでしょうか。 私も技術そのものというより、要件に合わせて技術を組み合わせる設計の問題だと思っています。加えて、JWTを利用することはそんなに難しいことかという疑問があった
HSTS (HTTP Strict Transport Security) の導入 - Qiita
HTTPで接続した際に、強制的にHTTPSへリダイレクトし、以降のそのドメインへの接続はすべてHTTPSとする機能がHSTS (HTTP Strict Transport Security) である。RFC6797で標準化されている。 これはHTTPヘッダに以下を含むことで実現される。 Strict-Transport-Security:max-age=有効期間秒数;includeSubDomains max-ageではHTTPSで通信する期間を設定する。また、includeSubDomainsを指定することで、サブドメインにもHSTSが適用されるように設定できる。 HSTSのサポートは、2015年6月9日にマイクロソフトがIEへのサポートを追加したことで、すべてのメジャーブラウザにおいてサポートが完了し、HTTPサーバーとしてもApacheを始めとし設定が可能だ。 Apacheの設定 A
AWSアカウントを取得したら速攻でやっておくべき初期設定まとめ - Qiita
AWSアカウントを作成したら最初にやっておきたいことをまとめてみた。 あわせて読みたい 本記事の内容を含めた最新の手順は、下記の書籍にまとまっている。 クラウド破産を回避するAWS実践ガイド AWSアカウント（ルートアカウント）の保護 AWSアカウントが乗っ取られると詰むので、真っ先にセキュリティを強化する。 AWSアカウントへ二段階認証を導入 AWSアカウントでのログインは、AWSアカウント作成時のメールアドレス・パスワードだけでできてしまう。心許ないにもほどがあるので、まずは二段階認証を設定しよう。 IAMのページを開く https://console.aws.amazon.com/iam/home 「ルートアカウントのMFAを有効化」を選択して、「MFAの管理」ボタンをクリック 「仮想MFAデバイス」にチェックが入っていることを確認し、「次のステップ」ボタンをクリック 注意書きを読ん
ソルトとハッシュ関数だけでパスワードをハッシュ化するのが微妙な理由 - Qiita
2019/12/29 追記 いまでもこの記事が時々参照されています。Googleなどからこの記事へとやってきた方は、パスワードか何か重要な情報をどう保存するか？ということを考えておられるかもしれません。もしそうであれば、ぜひこの記事のコメントも記事を読んだあとに参照していただきたいと思います。徳丸さんをはじめとして僕よりもはるかに知見のある方の考えなどもあります。ハッシュ化されたパスワードは、もしかしたら今これを読もうとしておられる方が作っているアプリケーションよりも長きにわたって利用されるかもしれません。少々の時間をいただきますが、そういう理由でぜひコメントのディスカッションも参考にしたうえで今できる最良のセキュリティーを実装していってください はじめに この記事ではパスワードを保存する際によく用いられるソルトとハッシュ関数を使うやり方について、なぜそれが微妙であるかを解説した後に、それ
「IoT開発におけるセキュリティ設計の手引き」を公開 | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
公開日：2016年5月12日 最終更新日：2024年3月29日 独立行政法人情報処理推進機構 技術本部 セキュリティセンター IPAセキュリティセンターでは、今後のIoTの普及に備え、IoT機器およびその使用環境で想定されるセキュリティ脅威と対策を整理した「IoT開発におけるセキュリティ設計の手引き」を公開しました。 概要 昨今、IoT（Internet of Things）が多くの注目を集めています。現在ではIoTと分類されるようになった組込み機器のセキュリティについて、IPAでは2006年から脅威と対策に関する調査を実施してきました。現在IoTと呼ばれる機器には、最初からIoTを想定し開発されたものの他に、元々は単体での動作を前提としていた機器に、ネットワーク接続機能が後付けされたものが多く存在すると考えられます。そのため、IoTの普及と利用者の安全な利用のためには、機器やサービスがネ
Java/ServletとJSESSIONIDのURL管理 - Glamenv-Septzen.net
Servlet 2.5 今回主に取り上げるTomcat6, Jetty7で対応しているServlet 2.5の仕様を確認すると、"SRV.7.1 Session Tracking Mechanisms"で以下のように記されています。 SRV.7.1.1 Cookies Session tracking through HTTP cookies is the most used session tracking mechanism and is required to be supported by all servlet containers. The container sends a cookie to the client. The client will then return the cookie on each subsequent request to the server,
感想： 体系的に学ぶ 安全なWebアプリケーションの作り方 - penultの日記
読んでます。 体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践 作者: 徳丸浩出版社/メーカー: SBクリエイティブ発売日: 2011/03/01メディア: 単行本購入: 119人 クリック: 4,283回この商品を含むブログ (146件) を見る まだ途中だけど、主にJava/Tomcatユーザとしての備忘メモ。ただし、セキュリティの専門家でも何でもないので間違いは大いにあると思われます。 HttpOnly 属性の指定（p.103） Tomcat では、Tomcat7以降（Servlet 3.0以降）なら単純に web.xml か web-fragment.xml に <session-config> <cookie-config> <http-only>true</http-only> </cookie-config> </session-confi
暗号化と圧縮、どちらを先にするべきか？ | POSTD
こんなことを想像してみてください。 あなたは大企業で働いています。仕事はかなり退屈です。端的に言えば、あなたの顔も見たくないという経理担当の3人しか使わないようなアプリケーションのために定型的なコードを書いて、才能を無駄にしているという状況です。 あなたが本当に情熱を注げるのはセキュリティです。毎日、 r/netsec を読み、仕事の後にはバグ報奨金プログラムに参加しています。ここ3カ月間は手の込んだ株式取引ゲームをプレイし、報奨金を得ています。ヒープベースのバッファオーバーフローを発見し、優良株を選ぶ手助けとなるAVRシェルコードをいくつか書いたからです。 あなたが取り組んできたビデオゲームが、実は巧妙な偽装のリクルートツールであったと判明し、全てが変わります。世界最高のセキュリティコンサルタント会社、Mont Piperが人材を募集していて、あなたは面接に行くことになったのです！ 飛行
Welcome to OWASP documents page by JPCERT/CC.
Japanese translation of OWASP documents View the Project on GitHub JPCERTCC/OWASPdocuments Download ZIP File Download TAR Ball View On GitHub Welcome to OWASP documents page by JPCERT/CC. JPCERT/CC で行っている OWASP ドキュメント日本語訳のベータ版ファイルを置いています. 参考: OWASP Japan チャプター (「Translation / OWASP ドキュメント翻訳」タブ) ASVS (Application Security Verification Standard) ASVS プロジェクトの github リポジトリ ASVS v3.0.1 日本語訳 (docx) (pdf
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PenTesterが知っている危ないAWS環境の共通点
IPA セキュア・プログラミング講座：Webアプリケーション編