サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
SPAのログイン周りについて、「これがベストプラクティスだ！」という情報があまり見当たらないので、様々な可能性を模索してみました。 いろいろな状況が想定され、今回記載する内容に考慮の漏れや不備などがありましたら是非コメントでご指摘いただきたいです！特に「おすすめ度：○」と記載しているものに対しての批判をどしどしお待ちしております！ この記事でおすすめしているものであっても、ご自身の責任で十分な検討・検証の上で選択されてください。 前提 想定しているAPIは、 ログイン外のAPIにはPOST/PUT/DELETEのものがなく、GETのみ GETのAPIにはDBを更新するなどの操作がない とし、そのためログイン外ではCSRFを考慮しなくてよい、 という前提で話を進めます。 また、XSSに関しては常に対策は必要なのですが（フレームワーク側が自動的にしてくれる部分もある）、認証周りに関係すること以
スライド概要 SPA(Single Page Application)の普及が一層進んでおり、従来型のMPAを知らないウェブ開発者も生まれつつあるようです。SPA対応のフレームワークでは基本的な脆弱性については対策機能が用意されていますが、それにも関わらず、脆弱性診断等で基本的な脆弱性が指摘されるケースはむしろ増えつつあります。 本セッションでは、LaravelとReactで開発したアプリケーションをモデルとして、SQLインジェクション、クロスサイトスクリプティング、認可制御不備等の脆弱性の実例を紹介しながら、現実的な対策について紹介します。LaravelやReact以外のフレームワーク利用者にも役立つ説明を心がけます。 PHPカンファレンス2022での講演資料です。 PHPカンファレンスでの動画URL https://www.youtube.com/watch?v=jZ6sWyGxcCs
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
タリーズの件、CSPが設置されていたら防げていたという話がありますが、それは正しいでしょうか？ CSPを設定していなかったとしても、想定していない外部へのリクエストが発生していないか、定期的にチェックすることも大事ですよね？ タリーズのサイトからのクレジットカード情報漏えいについて、CSP(Content Security Policy)やintegrity属性（サブリソース完全性）の重要性がよくわかったという意見をX(Twitter)上で目にしましたが、これらでの緩和は難しいと思います。 まず、CSPの方ですが、今回の件では元々読み込んでいたスクリプトが改ざんされたと考えられるので、オリジンとしては正規のものです。evalが使われていたのでCSPで制限されると考えている人が多いですが、evalは難読化のために使われているので、evalを使わないことは可能です。個人的には、難読化しない方が
株式会社メタップスペイメントの運営する決済代行システムから約288万件のクレジットカード情報が漏洩した不正アクセス事件について、第三者委員会の報告書および経済産業省の行政処分（改善命令）があいついで公開されました。 第三者委員会調査報告書（公表版） クレジットカード番号等取扱業者に対する行政処分を行いました （METI/経済産業省） 本稿では、主に第三者委員会の調査報告書（以下「報告書」と表記）をベースとして、この事件の攻撃の様子を説明します。 システムの概要報告書にはシステム構成図やネットワーク構成図は記載されていないため、報告書の内容から推測によりシステムの構成を以下のように仮定しました。 図中のサーバー名は報告書の記載に従っています。以下、概要を説明します。 サーバ名概要 A社アプリ一般社団法人A 会員向け申込みフォーム 経産省改善命令では、「同社とコンビニ決済に係る契約を締結してい
以下のツイートを読んで気持ちが昂ったので。 みんな、もうSNSでいがみ合うのはやめよう。 平和に好きなJWTの話でもしようよ。 JWTの格納場所はlocalStorageとCookieのどっちが好き？— 徳丸 浩 (@ockeghem) 2022年2月11日 というのも、JWTをセッションに使うときに保存先含めて一時期悩んでいたので、その時の自分の解。 ただ、考えるたびに変化しているので、変わるのかもしれない。 要約 タイトル。 あとは優秀な方々が既に色々考えておられるのでそちらを読むとよいでしょう。 SPAセキュリティ入門～PHP Conference Japan 2021 JWT カテゴリーの記事一覧 - r-weblife どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ - co3k.org JWT形式を採用したChatWorkのアクセストークンについて -
サマリとある通販サイトにて「 メールアドレス・パスワードを保存する」機能がありますが、サイトにクロスサイトスクリプティング(XSS)脆弱性がサイトにあると生のパスワードが漏洩する実装となっています。本稿では、この実装方式を紹介し、なぜ駄目なのか、どうすべきなのかを紹介します。 記事の最後にはセミナーのお知らせを掲載しています。 はじめに家人がテレビを見ていて欲しい商品があるというので、あまり気は進まなかったのですが、その商品を検索で探して購入することにしました。「気が進まない」というのは、利用実績のないサイトはセキュリティが不安だからという理由ですが、この不安は的中してしまいました。 最初の「えっ?」はパスワード登録のところでして、パスワードを再入力する箇所で「確認のためもう一度、コピーせず直接入力してください」とあるのですよ。私は乱数で長く複雑なパスワードを入力しかけていたのですが、コピ
セキュリティは難しいです。 ですが、プログラミング初学者の皆さんは必要以上に萎縮せず、どんどんアプリケーションを作り、公開することにチャレンジして欲しいと私は思っています。 一方、事実として、脆弱なアプリケーションが公開されている（サーバ上でアクセス可能な状態になっている）だけで、全く無関係な第三者が被害を被る可能性があることは知っておく必要があります。 それはWordPressを使った単なるWebサイトであったとしても同じです。 また、あなたのアプリケーションが破壊されて困らないものであったり、 個人情報を保持していないものであったとしても、です。 だから、知らなかった、では済まされないこともあります。 この記事では、PHPのソースを例に、 特にプログラミング初学者が生み出しやすいアプリケーションの脆弱性について、 具体的なコードを挙げながら解説します。 なお、本記事のサンプルコードはも
はじめに こんにちは。株式会社Flatt Securityのセキュリティエンジニアの冨士です。 本稿では、XSS(クロスサイトスクリプティング)が攻撃に用いられた時のリスクの大きさを紹介していきます。以降はクロスサイトスクリプティングをXSSと記載していきます。 XSSはセキュリティエンジニアならもちろん、開発を行っているエンジニアの多くの方が知っている脆弱性です。ですが、私はWebアプリケーションの脆弱性診断を行ってきた経験の中で多くのXSSを目にしてきましたし、依然として検出率の多い脆弱性の一つだと感じています。 その認知度や、一般的な対策方法のハードルの低さ(設計や仕様によっては対策工数が大きい場合もありますが)にも関わらずXSSの検出率が多いのは、直感的にリスクがわかりづらく、アラートをあげるだけの紹介が多いことが一つの要因ではないかと考えています。 すなわち、興味範囲が「どのよう
CSRF 対策は One Time Token を form なりに付与して、サーバ側でチェックすれば良い。 それをデフォルトでサポートしてるフレームワークなどもあるし、なくてもライブラリでいくらでも対応できる。 どうせ完全にステートレスなサービスはなかなかないので、サーバ側に redis や memcache を用意するのも別に大変じゃない。 なので、 CSRF 対策として Token を付与するのは、最も安全で推奨できる方式ではある。 っていうのを踏まえた上で、もう SameSite=Lax デフォルトだけど、今でも Token 必須なの？みたいなのがたびたび話に出るので、いい加減まとめる。 前提 この話は、スコープがどこなのかによって話が多少変わるので、そこを絞る。 今回は Passive ではなく Active に対策していく場合を考えるので、前提をこうする。 SameSite=l
Slackでも昔はポップアップや警告ダイアログが出ないで攻撃のリンクに飛ばされていた時期があり、当初Slack側は「ワークスペース内のメンバーの対立が前提」と延べ、脆弱性を認めていなかったが、外部からのメールの注入などで起こりうる可能性があるとして、脆弱性と判断した背景があります。 やりとりはこちら https://hackerone.com/reports/481472 我々は、日々開発していく中で、URLを扱うことはとても多いです。 それこそ、**<サービス名>**などでも今後、URLに自由な表示文字を設定できるようになる仕様が出てくるかもしれないです。 新しいサービスを作る時に要件が上がってくるかもしれないです。 そうなった時に、今回のような脆弱性のパターンを思い出してもらい、回避することで安全なサービスを作っていきましょう。 二要素認証（2020/05/14） みなさん、**二段階
サマリ ISO-2022-JPという文字エンコーディングの自動判定を悪用したクロスサイト・スクリプティング(XSS)攻撃について説明する。これは、文字エンコーディングを適切に指定していないウェブコンテンツに対して、文字エンコーディングをISO-2022-JPと誤認させることでバックスラッシュが円記号と解釈されることによりエスケープ処理を回避する攻撃である。本稿で紹介する攻撃は、従来からのセキュリティベストプラクティスである「文字エンコーディングの明示」に従っていれば影響を受けることはない。 はじめに クロスサイト・スクリプティング対策として、記号文字のエスケープ処理に加えて、コンテンツの文字エンコーディングをレスポンスヘッダやmetaタグで明示しましょうと言われてきました（参照）。その背景として、UTF-7という文字エンコーディングを悪用したXSSの存在がありました。この攻撃については以下
【セキュリティチームブログリレー2回目】 こんにちは。エンジニアリンググループの山本です。 セキュリティチームは、エンジニアリンググループ全体のセキュリティを向上させるためのバーチャルチームなのですが、各プロダクト開発チームのサービスをチェックして、協力しながら全体のセキュリティを向上させていくのがミッションです。 そのお仕事の一環として「この部分、セキュリティヘッダが足りないから入れてください！」というやりとりを日常的に行なっています。 今日はこの「セキュリティヘッダ」というものが一体何なのか、今さら人に聞けないアレコレを取りまとめてみたいと思います。 セキュリティヘッダ警察の日常の図(もちろん冗談です) セキュリティヘッダ そもそもセキュリティヘッダとは？ 比較的安全なセキュリティヘッダ X-Content-Type-Options X-XSS-Protection Strict-Tr
2020年7月現在、転職活動をしています。お気軽にお問い合わせください。 https://docs.google.com/forms/d/e/1FAIpQLSfNuWiDVcCCZ58XjPn2nZIqtYOHo0XAuTMgIZisSYLbfiIcnA/viewform https://twitter.com/bulkneets/status/1279236615546654720 いわゆる履歴書や職務経歴書 要するに mala とは何者なのか？ プログラマ、デザイナー、ライブドアの残党 専門領域はWebに関わること全般 セキュリティエンジニアとして認識されることを本人は嫌っていますが、そのように認識されることも多いようです 説明が面倒くさい時に自分からsecurity researcherを名乗ることはたまにあります 実績は CVEや、善行からリンクされているページを見てください。 実
メリークリスマス！ 週末もPHPを楽しんでますか？ ところでWebセキュリティはWebアプリケーションを公開する上で基礎中の基礎ですよね！ メジャーな脆弱性を作り込まないことはWeb開発においては専門技術ではなく、プロとしての基本です。 中でもXSS (Cross-Site Scriptingクロスサイトスクリプティング)やインジェクションについての考慮は常に絶対に欠いてはならないものです。 現実にはプログラミングには自動車のような運転免許制度がないため、自動車学校に通わず独学で公道に出ることができてしまいます。つまりは基礎知識がないままにWebプログラマとして就職したり、フリーランスとして案件を請けることも現実には罷り通っています。それは一時停止標識も赤信号も知らずにタクシー営業しているようなものです。 このような事情により、体系的な理解のないWeb開発初心者は (時にはn年のキャリアを
例えば、Content-Typeメタデータの値を細工したオブジェクトを取得させることでXSSを発生させたり、Content-Dispositionメタデータを細工してRFD (Reflected File Download) を引き起こしたり、 x-amz-storage-classメタデータを操作して意図せぬストレージクラスを使用させEDoS (Economical Deninal of Sustainability)を発生させたり、といった攻撃が成立する可能性があります。 中でもContent-Typeを悪用したXSSは、S3の仕様や使用方法だけでなく、ブラウザの挙動にも注意を払う必要があり、アプリ開発者は攻撃の原理と対処を理解しておく必要があります。 9/21にAzaraさんとSecurity-JAWSのコラボで、この問題にフォーカスしたCTFイベント「とある海豹とSecurity-
SPAのアプリケーションで、外部のIdPを使ってOpenID Connect によるログイン機能を開発しようと考えています。IDトークンの保存先として、ブラウザのCookieかサーバーのDBに保存するかの2つの案があると思っています。調べた限り、サーバーサイドで持つべきという意見が多いように見えますが、以下のような背景がある中で開発しても、ブラウザのCookieでは持つべきなのではないのでしょうか？ - IDトークン自体にも、個人の属性（氏名等）情報は無いことを確認している - サーバーサイドでIDトークンの署名検証をして、IDトークンの改ざんが無いか確認する - Http Only属性：JSによるCookieへのアクセスを防ぐため - Secure属性：流出防止のため - SameSite=strict：CSRF対策のため 結論から言えば、「どちらでもよい」となります。しかし、恐らく話は
ある時Twitterのタイムラインを見ていたら、「JavaScriptをWasm化して動かす意味がわからない」というような意見を見かけました。JavaScriptはブラウザに搭載されているV8のようなJavaScriptエンジンによって高速に動作するので、わざわざWasm化してもパフォーマンスは劣化するのになぜなのか?という話なんですが、これは「Wasm化=パフォーマンスのため」という考えだと意義がわからないのでこの記事ではそれについて解説します。 JavaScriptをWasm化して動かすツールやライブラリとしては、Shopifyが開発しているJavyやquickjs-emscriptenなどがあります。JavaScriptをWasm化して動かすためには、ある特定のJavaScriptエンジンをWasm向けにビルドして動かす必要がありますが、そのような用途ではQuickJSというJava
※追記: 本記事の続編としてin-memory方式からアクセストークンを奪取するPoCを下記記事で公開しました。ぜひあわせてご覧ください。 はじめに こんにちは。 セキュリティエンジニアの@okazu-dm です。 この記事では、Auth0のSPA SDKでアクセストークンのキャッシュを有効化する際の考慮ポイントについて紹介し、それを切り口にアクセストークンの保存場所に関してin-memory方式とlocalStorage方式の2つについて解説します。 Auth0のようなIDaaSは昨今かなり普及が進んでいると思いますが、Flatt Securityの提供するセキュリティ診断はAuth0に限らずFirebase AuthenticationやAmazon CognitoなどのIDaaSのセキュアな利用まで観点に含めて専門家がチェックすることが可能です。 ご興味のある方は是非IDaaS利用部
国内の主要なSaaS企業やSIerに脆弱性診断サービスなどを提供しているFlatt Security社は、Webエンジニアがセキュアコーディングを独習できるオンライン教材「KENRO」のトライアルとしてコンテンツの一部を無料で公開中です。 メールアドレスを登録するだけで利用を開始でき、期間も無制限。 KENROでは「SQLインジェクション」「XSS（クロスサイトスクリプティング）」「ディレクトリトラバーサル」などを始めとする10種類の一般的な脆弱性についてテキストで学び、その学びを基に攻撃者として脆弱性に対する攻撃を「ハッキング演習」で試し、その脆弱性があるコードを自分で修正する「堅牢化演習」まで、オンラインで実践できるユニークな教材です。 演習の結果もKENROが自動判定してくれるため、24時間365日、いつでも学習できます。 無料トライアルでは、一般的な10種類の脆弱性の学習コンテンツ
はじめに こんにちは。 セキュリティエンジニアの@okazu-dm です。 この記事は、Auth0のアクセストークンの保存方法について解説した前回の記事の補足となる記事です。前回の記事の要旨をざっくりまとめると以下のようなものでした。 Auth0はデフォルトではアクセストークンをブラウザのメモリ空間上にのみ保存するin-memory方式であり、XSSへの耐性のなさ等の理由でlocalStorageで保存することを推奨していない しかし、XSSでアクセストークンを奪取できるのはin-memory方式でも同じのはず(検証は行いませんでした)。localStorage方式を過度に忌避する必要はないのではないか なお、Flatt Securityの提供するセキュリティ診断はAuth0に限らずFirebase AuthenticationやAmazon CognitoなどのIDaaSのセキュアな利用
JavaScript / TypeScript の豆知識 10 選 初めに JavaScript / TypeScript にまつわる豆知識を、10 個ほど集めてみました。 コードは全て TypeScript で書いていますが、内容はほぼ全て JavaScript にも当てはまることです。 少し長めの読み物ではありますが、気軽に当記事を楽しんで頂ければ幸いです。 それでは、以下が目次です。 JavaScript / TypeScript の豆知識 10 選 初めに 1.Nullish と Falsy 関連参考資料_1 2. tsconfig の便利な設定 関連参考資料_2 3. 依存関係の綺麗な図示の仕方 関連参考資料_3 4.正しい XSS のやり方 関連参考資料_4 5.removeChildren 関連参考資料_5 6.数値型を関数の引数として使う時の小技 関連参考資料_6 7.hi
ちょっとでもセキュリティに自信がないなら、 Firebase Authentication を検討しよう （※ こちらの参照記事の内容自体に不備があるとか甘いとか指摘するものではないんですが、勝手に枕として使わせてもらいます） 上記記事は、Firebase Authenticationが提供するJavaScript APIを使ってJWTのトークンを取得し、自前のサーバにHTTPのヘッダで送りつけて検証をさせることで、認証の仕組みをセキュアかつかんたんに実現しよう、という内容です。 このようにJavaScriptのAPIでトークンを発行して自前バックエンドのAPI認証につかう方法はAuth0のSDKなどでも行われていますので、IDaaSをつかってSPAを開発する場合には一般的なのかもしれません。 話は変わりますが、SPAの開発に携わっている方は「localStorageにはセッション用のトー
はじめに セキュリティエンジニアの齋藤ことazaraです。今回は、不可思議なContent-Typeの値と、クラウド時代でのセキュリティリスクについてお話しします。 本ブログは、2024 年 3 月 30 日に開催された BSides Tokyo で登壇した際の発表について、まとめたものです。 また、ブログ資料化にあたり、Content-Type の動作や仕様にフォーカスした形で再編を行い、登壇時に口頭で補足した内容の追記、必要に応じた補足を行なっています。 また、本ブログで解説をする BSides Tokyoでの発表のもう一つの題である、オブジェクトストレージについては、以下のブログから確認をすることが可能ですので、ご覧ください。 blog.flatt.tech なぜ今、この問題を取り上げるのか？ 従来のファイルアップロードにおいて、Content-Type の値を任意の値に設定すること
安全なウェブサイトの作り方を読んだので、理解した内容を自分なりにまとめておきます。資料 上記は3章構成になっていてそれぞれ長めの内容なので、ここでは3章の『失敗例』について、Ruby on Rails ではどうするかについてをまとめます。 SQL インジェクション OS コマンドインジェクション パス名パラメータの未チェック例（ディレクトリトラバーサル） 不適切なセッション管理例（セッション ID の推測） クロスサイト・スクリプティングの例（エスケープ処理） CSRFの例 HTTP ヘッダ・インジェクションの例 メールヘッダ・インジェクションの例 参考 SQL インジェクション 参考資料内の SQL インジェクション例を見て、Ruby on Rails ではどのように対策できるかを確認しました。 例えば、下記ような $uid, $pass をユーザ入力とし、SQL 文を動的に生成する場合
はじめに WEBエンジニアとして成長するために、セキュリティ対策は避けては通れない道ですよね。 僕も含め 「なんとなく知ってる」 という方は多いのではないでしょうか。 大切なWEBサイトを守るためにも、WEBエンジニアとしての基礎を固める為にも、しっかりと学んで一緒にレベルアップしていきましょう。 また、本記事の内容は様々な文献をもとに自身で調べ、試したものをまとめています。 至らぬ点や、間違いがありましたら、コメントにてご指摘をお願いします。 他にも様々な攻撃手法についてまとめているので、興味のある方は読んでみてください。 攻撃から学ぶXSS対策 攻撃から学ぶSQLインジェクション対策 CSRFって何？ CSRF（Cross-Site Request Forgery）とは、サービスの利用者に意図しないHTTPリクエストを送信させ、意図しない処理を実行させる攻撃手法です。 これだけでは分か
Vue.js logo: ©︎ Evan You (CC BY-NC-SA 4.0 with extra conditions(It’s OK to use logo in technical articles for educational purposes)) / React logo: ©︎ Meta Platforms, Inc. (CC BY 4.0) / Angular logo: ©︎ Google (CC BY 4.0) はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの森(@ei01241)です。 最近のJavaScriptフレームワークの進化は著しく、VueやReactやAngularは様々なWebサービスに採用されています。そのため、多くのWebサービスがSPAを実装するようになりました。JavaScriptフレームワークは便利な一方で
PHPのstringは任意のバイト列を扱えますが、JavaScript/JSONはUnicodeで扱える文字しか扱えません PHPのint / floatはプラットフォーム依存ですが、JavaScriptのnumberは整数と小数を型レベルで区別しません JSONのarrayに対応する型はPHPのarrayのうちリストであるものです PHPは配列(リスト)と連想配列を型レベルで区別せず、どちらもarrayです リストはキーが0からの抜けがない連番になっている要素が0個以上の配列です array_is_list()関数で連想配列とリストを判別できます array_values()で連想配列をリストに変換できます array_filter()の結果はフィルタされたキーがスキップされるのでリストではありませんが、結果をarray_values()に通すことでリストにできます JsonSerial
「Xbox Series S」、予約開始前に値下げ 3万2980円→2万9980円に 「市場の状況を考慮」 日本マイクロソフトは9月24日、25日から予約を受け付ける予定の次世代ゲーム機「Xbox Series S」の価格を改定すると発表した。当初は3万2980円（税別、以下同）と発表していたが、2万9980円に変更する。「市場の状況やユーザーのニーズを考慮した」（同社）という。 Xbox Series Sは、同じく25日に予約受け付けを始める次世代ゲーム機「Xbox Series X」の廉価版。Xbox Series Xと違い、デジタル配信ゲームのみに対応する。Xbox Series Xの価格や、両モデルの予約販売の開始日は変更しない。 Xbox Series Sは11月10日に発売する予定。次世代ゲーム機を巡っては、ソニー・インタラクティブエンタテインメント（SIE）が9月17日に「P
最近年2回のサイボウズ以外はほぼバグバウンティしていない現状であるが、やる気が起きたときようにメモ 主にWebアプリに関すること 診断と自分で勝手に脆弱性を探す行為との違い 網羅性は全く必要ない 診断は網羅してないと怒られることがあるが好きな脆弱性だけ探せる。 期間が永遠 診断期間は自由なので後で気づいて頭を抱えることはない 攻撃に到るまでを説明する必要がある 「バージョンが古いのでダメです」だけでは許してもらえない 変なことすると逮捕される可能性がある 無闇にツール回すと不正アクセス禁止法に引っかかるので だがしかし海外勢は法律の違いもあるのか好きなサイトに気軽にツールを回すので太刀打ちできない 日本人としては許可されたところかローカルに環境作って攻撃するのが心理的安全性が高い 2023年度の傾向 コモディティ化が進む 自分だけしか知らないような脆弱性はない まだ知られていない手法もほぼ
社名にHTMLスクリプトタグを採用したソフトウェア開発企業が、企業登記所から「データベースの脆弱(ぜいじゃく)性につながる」として社名変更を強制されたという事例が、ソーシャルニュースサイトのHacker Newsで話題となっています。 Company forced to change name that could be used to hack websites | UK news | The Guardian https://www.theguardian.com/uk-news/2020/nov/06/companies-house-forces-business-name-change-to-prevent-security-risk UK govt aims to kill off Bobby Tables in Companies House name rules https:
Hello there, ('ω')ノ これまで、実例をもとに学んだ脆弱性診断につかえる実践的なテクニックは以下のとおりで。 ・サブドメインの1つに403を返すエンドポイントがある場合は、通常のバイパスは機能しないので、Refererヘッダを変更すると200 OKが取得できる場合があります。 ・エンドポイントのディレクトリとリクエストボディを削除して、メソッドを「PUT」から「GET」に変更すると隠されたエンドポイントに関する情報を取得できる場合があります。 ・見つけたエンドポイントに通常アカウントで403エラーが発生した際、管理者アカウントのjsonリクエストの本文と比較して差分のパラメータを追加するとアクセスできる場合があります。 ・Linux環境でコマンドを実行する際、スペース文字をバイパスするためのペイロードは以下のとおりです。 cat</etc/passwd {cat,/etc/
スライド概要 シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXk
攻撃者は、はじめに標的のECサイトの注文フォームに対し、不正なスクリプトを含んだ文字列を入力し、購入処理を行います（図1の①）。その結果、ECサイトの購入処理の部分にXSSの脆弱性が存在する場合、ECサイトの管理画面を閲覧した管理者は不正なスクリプトが実行され、クレデンシャル情報の窃取や、ECサイトへの簡素WebShellの設置などが行われます（図1の②～④）。その後、攻撃者によってECサイトにWebShellやユーザーの情報窃取を行うJavaScriptなどが設置されます。設置された“情報窃取JavaScript”によってECサイトを利用するユーザーのクレジットカード情報等を窃取され、“情報保存ファイル”としてECサイト内に保存されます（図1の⑤）。攻撃者は定期的なWebShellへのアクセスを行うことでこれらの情報を窃取していたと推測されます（図1の⑥）。 なお、攻撃者は、一連の攻撃の
はじめに こんにちは！CTOのはせがわです。 先日公開された、Flatt Securityさんのブログ「開発者が知っておきたい「XSSの発生原理以外」の話」、おもしろいですね。このXSSの記事に限らず、Flatt Securityさんのブログは役に立つ記事が多い*1ので、個人的には記事が公開されるのを毎回楽しみにしています！*2 たしかに、XSSの脅威についてはなかなか理解してもらうことが難しく、また一般的にはSQLインジェクション等と比べても脅威が低く見られることも多いため、XSSの脅威について少し掘り下げて考察したいと思います。 なお、この記事は「XSSの発生原因くらいは知ってるよ」という人を対象にしています。「XSSって何だっけ」という方は クロスサイトスクリプティング対策 ホンキのキホン (1/3)：CodeZine（コードジン） などの記事を参照してください。 技術的な面からの解
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
