限定公開URLについて適当に書く - 日々量産
過去に限定公開URLっぽい機能を実装したので、その時考えていたことを書こうと下書きを始めてから1年以上経ったものを手直しして公開しています。具体的なコードとかは出てきませんし、終始フワフワした感じで歯がゆい感じかもしれませんが、ごめんなさい。 はじめに まず、限定公開URLについては、渋川よしき先生のスライドが詳しいです。特にURLに使う識別子(?)の長さにおけるセキュリティ強度の各サービスの比較と検討に関するページは貴重なまとめだと思います。 （URLの性質を考えればできることは知っていたが、Capability URLといった呼び方があることを知ったのがこのスライドでした） docs.google.com またスライドでも触れられているW3CのCapability URLのデザインに関する記事もわかりやすいです。 どういうものか、使い時、注意点といった話もすべて書かれています。 w3c
2021年 人気脆弱性 TOP 10 in GitHub - まったり技術ブログ
はじめに 2021年 人気脆弱性 TOP 10 in GitHub 10位 975 pt 『Microsoft Windows Server における権限を昇格される脆弱性 (CVE-2021-42287)』 9位 1,005 pt 『Apache Druid における重要なリソースに対する不適切なパーミッションの割り当てに関する脆弱性 (CVE-2021-25646)』 8位 1,068 pt 『Microsoft Windows Server における権限を昇格される脆弱性 (CVE-2021-42278)』 7位 1,149 pt 『VMware vCenter Server および Cloud Foundation における権限管理に関する脆弱性 (CVE-2021-21972)』 6位 1,557 pt 『 Apache HTTP Server におけるディレクトリトラバーサルの
GraphQL API を悪意あるクエリから守る手法 - yigarashiのブログ
実サービスで GraphQL API をインターネットに公開する際は、悪意あるクエリに対する防衛が欠かせません。この記事における「悪意あるクエリ」とはサービスに意図的に負荷をかけるクエリのことです。GraphQL では 、木構造や再帰的な構造を利用して、一回のクエリで容易に数百万・数千万件のデータを取得することができます。そのようなクエリを実行してしまうと、アプリケーションサーバーや、その後ろにいる別のサービスに甚大な負荷がかかります。これは攻撃者からしてみれば恰好の的で、なんらか対策を講じる必要があります。 幸いこうした問題はよく知られており、クエリを静的に解析するライブラリがいくつか存在します。しかし、そうしたライブラリをどう使うかといったことはあまり議論されておらず、効果的な対策を行うのは依然として難しい状況だと感じます。この記事では、典型的な負荷の高いクエリとその具体的な対策を紹介
JWTを使った今どきのSPAの認証について | HiCustomer Lab - HiCustomer Developer's Blog
TL;DR JWTはCookieを使った認証の代わりに使うのはきつい。 コードを静的にホスティングしているSPAの話。 JWTの有効期間を長くすれば危険で、短くすればUXが犠牲になるというトレードオフがある。 AWS AmplifyはlocalStorageにJWTを保存 悪意のあるThird partyライブラリが混ざっていたらJWTを抜かれる。 yarn.lockが依存している全ライブラリを監査することはつらい。 Auth0ではiFrameを活用してメモリ上にJWTを格納できる Auth0いいね😍 まくら Youtubeが大好きなHiCustomerの小田です。ちょっと遅いですが年明け最初のエントリーです。今年もテックブログをよろしくお願いします😎ちなみに、気分がいいので年明けに観ていたYoutubeのエントリーの中で一番おもしろかった動画を紹介します。世界中で有名な「Auld L
ヘッドレスブラウザとSSRF | MBSD Blog
ヘッドレスブラウザは、サーバ環境などでHTMLをレンダリングするためにバックグラウンドで動作させるブラウザです。 筆者も昨年診断ツールに組み込んだのを契機に使用し始めました。使ってみるとなかなか面白いので、今年は社内での学習用の「やられサイト」にも組み込んでみました。今回はこのやられサイトを題材にして、ヘッドレスブラウザとSSRF（Server-side request forgery）について書きます。 やられサイトの概要 開発したやられサイトは簡単なブックマークサイトです。ユーザがURLを入力すると、そのスクリーンショット画像をヘッドレスブラウザで取得して、ユーザが付けたコメントなどの付加情報とともに保存します。 下図はヘッドレスブラウザに関連する部分の構成です。 図のとおりNode.jsのPuppeteerを使用しており、バックエンドのブラウザエンジンはChromiumです。性能向上
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べたAPIOAuthWeb TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる 使い方について詳しくはこの記事の下のほうに書いた 要求 トークンを利用した認証・認可機構を持つ API を作りたい クライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークン ヘッダでトークンを送る API あるよね、ああいうやつ 疑問 Authorization: Bearer ヘッダは OA
安全で便利な Webhook を作る
安全で便利な Webhook を作る Tweet Webhook をご存知でしょうか。GitHub やその他のサービスで提供されているあの機能です。 今回は弊社の Komoju API で Webhook を提供する際に気づいた、webhook 実装上の注意点について書きます。 内部のサーバーへのアクセスを禁止する 一般的な Webhook はユーザーが送信先となる任意のURLを指定して、サービスはそこに対してPOSTリクエストを送信します。 このときに気をつけないといけないのは「そのURLがサービス内部のホストかどうか」を識別しなければならないということです。 たとえば localhost とか、内部 DNS のドメインとかです。このような宛先への Webhook 送信を許可してしまうと、本来は外部から隔離されてアクセスできないはずのサーバーに Webhook送信サーバー経由でアクセスで
明日から使える?! PATHでXSSする技術/ Shibuya.XSS techtalk #7
Shibuya.XSS techtalk #7 の資料です。
まもなく公開される CSP Level3 の変更点 - ASnoKaze blog
Content Security Policy Level 3のFirst Public Working Draftがそろそろ公開されそうです。 W3Cのgithubリポジトリより公開予定の仕様が確認できます。 https://w3c.github.io/webappsec-csp/published/FPWD-2015-01.html CSP2からの変更点 CSP3では主に以下の点が変更されたようです( https://w3c.github.io/webappsec-csp/published/FPWD-2015-01.html#changes-from-level-2 )。 1. FETCHの仕様の用語で一から書きなおされました。これにより、CSPの要求と制限が他の仕様と整合性が取れるようになりました（特にService Workersの仕様）。 2. CSP Level2で非推奨とな
CORSでハマったことまとめ - pixiv inside [archive]
こちらは ピクシブ株式会社 Advent Calendar 2014 の12/16の記事です。 こんにちは、エンジニアの@dnskimoです。 先日、はじめてCORSを実装する機会があったので、覚書がてらまとめておきたいと思います。 CORSとは Cross-origin resource sharingの略です。 読み方は「コルス」でいいんでしょうか？ Same-Origin Policyに弾かれずに、異なるドメイン間でリソースを共有する仕組みです。 2014年1月にW3C勧告になり、JSONPに替わる方法として徐々に普及してきているようです（要出典）。 アクセスコントロールの仕様も定義されているので、特定のサイトからのみ利用可能なAPIを作る際などに便利です。 JSONPのような「裏ワザ」的な方法ではないところも個人的に好みです。 詳しいことはネット上に素晴らしい記事がたくさんあるので
![CORSでハマったことまとめ - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5f6a93da881857fccf6161c1a2f6935458bfbb97/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fd%2Fdevpixiv%2F20141216%2F20141216151227.jpg)
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
SQLインジェクション対策もれの責任を開発会社に問う判決
ポイントは下記の通りです。 X社（原告）はセキュリティ対策について特に指示はしていなかった 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった（2010年1月29日） X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた（2010年9月27日）が、その後X社は改良の指示をしなかった 以下の脆弱性その他が認められた システム管理機能のIDとパスワードが admin/password であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能（ディレクトリリスティングと意図しないファイ
ModSecurity - セキュリティリスクを軽減するWebアプリケーションファイアウォール MOONGIFT
これは要導入検討ですね。 Webアプリケーションをセキュアに開発するのは基本ですが、それでも人が作るものである以上バグを含んでしまうのは致し方ありません。そこで未知の不具合を含めて防衛するための手段を考えなければなりません。 その一つとして、さらに外部からのアタックに対して考えられる手段がWebアプリケーションファイアウォール、通称WAFです。各種Webサーバに組み込めるオープンソースのWAF、それがModSecurityです。 デモが用意されておりインジェクションを起こそうと試みることができます。 特徴 ModSecurityの特徴として、多彩なWebサーバに対応しているというのがあります。Apache/nginx/IISサーバに対してインストールが可能です。また、以下のような特徴があります。 HTTPトラフィックのロギング 通常、Webサーバのログではリクエストボディは保存されません。
OAuth2.0の備忘録的まとめ - Ari-Press
Web系技術を学ぶ上で，やはりセキュリティ周りの技術は外せません。OAuth1.0ならばTwitter APIを触っていたんですが、、いつの間に2.0に！ということで、頑張って仕様書を読みつつ自分なりにまとめてみました。 The OAuth 2.0 Protocol draft-ietf-oauth-v2-10 を参考にしています。 また、以下で特に明示されない引用部分は全て The OAuth 2.0 Protocol draft-ietf-oauth-v2-10 から引用したものとします。 更に、以下の文章は2012/12/28時点でのAriの理解をまとめたものであり、内容を保証するのはこの時点でのAriの読解力のみです。 OAuth2.0の必要性 通常、ログインが必要なサービスを利用する際はログインID/パスワードの情報が必要になります。 特定のWebサービスに必要な時にアクセスする
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
SinatraでCSRFのチェック - GIOの日記
SinatraっていうかRackのミドルウェアでありました。 sudo gem install rack_csrf# app.rb require 'rubygems' require 'sinatra' require 'rack/csrf' get '/' do @msg = 'Hello World' erb :index end post '/' do @msg = 'Hello CSRF' erb :index end configure do set :app_file, __FILE__ use Rack::Session::Cookie, :secret => 'change me' use Rack::Csrf, :raise => true end helpers do def csrf_token Rack::Csrf.csrf_token(env) end def
OAuth 2.0でWebサービスの利用方法はどう変わるか（1/3）- ＠IT
OAuth 2.0で Webサービスの利用方法はどう変わるか ソーシャルAPI活用に必須の“OAuth”の基礎知識 株式会社ビーコンIT 木村篤彦 2011/2/2 TwitterがOAuth 1.0を採用したのを皮切りに、今では多くのサービスがOAuth 1.0に対応しています。国内でも、例えば、マイクロブログ型コラボツール「youRoom」、小規模グループ向けグループウェア「サイボウズLive」、「はてな」のいくつかのサービス、「Yahoo!オークション」、リアルタイムドローツール「Cacoo」などがOAuth 1.0に対応したAPIを公開しています。 ここ数年でOAuthはさまざまなWebサービスのリソースを利用する際の認証方式として普及してきました。これは大きなプレーヤーがサポートしたことも一因ですが、OAuthの持つ以下の2つの特徴によって、「OAuthを使うと、サービスプロバイ
RFCとなった「OAuth 2.0」――その要点は？
RFCとなった「OAuth 2.0」――その要点は？：デジタル・アイデンティティ技術最新動向（2）（1/2 ページ） いまWebの世界では、さまざまなWebサービスが提供するプラットフォームと、サー ドパーティが提供するアプリケーションがAPIを中心に結び付き、一種の「APIエコノミー」を形成しています。この連載では、そこで重要な役割を果たす「デジタル・アイデンティティ」について理解を深めていきます。 再び、デジタル・アイデンティティの世界へようこそ 前回「『OAuth』の基本動作を知る」ではOAuthの仕様がどういうものかについて説明しました。今回は引き続き、 OAuth 1.0とOAuth 2.0の違い OAuth 2.0をセキュアに使うために知っておくべきこと について述べていきます。 OAuth 1.0とOAuth 2.0の違い クライアントタイプの定義 OAuth 2.0では、O
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Signed HTTP Exchanges (SXG)とはなにか/SXG Explained
RESTを自称してはいけない
