Developers Summit 2023 10-A-4 「フロントエンド開発のためのセキュリティ入門」の発表資料です。 https://event.shoeisha.jp/devsumi/20230209/session/4176/ 「HTTPS化」「CORS」「XSS」「脆弱なライブラリのチェック」について説明しています。
![フロントエンド開発のためのセキュリティ入門](https://cdn-ak-scissors.b.st-hatena.com/image/square/206bc6ebcb3786432998d0f65715b6adace88d8a/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F98ea5595dd704bf2a804082a7544f93d%2Fslide_0.jpg%3F24447197)
スライド概要 SPA(Single Page Application)の普及が一層進んでおり、従来型のMPAを知らないウェブ開発者も生まれつつあるようです。SPA対応のフレームワークでは基本的な脆弱性については対策機能が用意されていますが、それにも関わらず、脆弱性診断等で基本的な脆弱性が指摘されるケースはむしろ増えつつあります。 本セッションでは、LaravelとReactで開発したアプリケーションをモデルとして、SQLインジェクション、クロスサイトスクリプティング、認可制御不備等の脆弱性の実例を紹介しながら、現実的な対策について紹介します。LaravelやReact以外のフレームワーク利用者にも役立つ説明を心がけます。 PHPカンファレンス2022での講演資料です。 PHPカンファレンスでの動画URL https://www.youtube.com/watch?v=jZ6sWyGxcCs
表題の通り、お恥ずかしい限りではありますが、人生ではじめて警察(神奈川県警!)のお世話になる運びとなりました。 罪状としては「不正指令電磁的記録 取得・保管罪」、通称ウイルス罪とのことで、まさに青天の霹靂の思いです。 以下ではこの度起こったことを可能な範囲でありのまま共有できればと思います。 この記事の目的まず、この記事を公開した目的は「他のクリエイターの人に同じ経験をして欲しくない」という一点に尽きます。 手前味噌ではありますが、私はこれまで多くの尊敬するクリエイターの方々と同じように「良いクリエイターであろう」と腐心し、できうるかぎりの努力をしてきたつもりです。 今回の件に関しても決して私利私欲のためではなく、あくまでユーザーのためにできることを、と模索した結果でした。 それがこのような形で取り沙汰されることとなり、残念という他ありません。 忸怩たる思いではありますが、この件から何かし
はじめに Dockerを開発環境で使うことが多くなってきてますね。 使い捨てできる環境は本当に便利なので、本番環境にも使いたいなーと思って、本番運用で注意すべきセキュリティ周りを調べてみました。 基本的な考え方 基本的な考え方は以下になります。 コンテナ内部に入られるな 権限は最小限にせよ 監視を怠るな DockerといえどVPSやオンプレのセキュリティ設定と考え方は同じですね。 ここではDockerにまつわる話を書いていきます。 コンテナ内部に入られるな 信頼できるイメージを使う 多くの場合、ベースとなるピュアなOSイメージはDockerHub上のイメージを使いますが、元となるイメージがセキュアであるかどうかを確認して使うようにしましょう。 既知の脆弱性を含んでいる場合や、最悪の場合、悪意のあるスクリプトが仕込まれている場合があります。 既知の脆弱性が含まれているかどうかはDocker
ダークウェブとダークネット 2017.10.06 Updated by WirelessWire News編集部 on October 6, 2017, 07:00 am JST NHKが不用意に「ダークネット」という用語を受け売りしたため、今後、この言葉は、違法な薬物や武器、個人情報などが取り引きされる闇のネットという意味で使われるようになるかも知れない。 例えばダークファイバーというのは、事業者が敷設だけしていて使っていない光ファイバー回線のこと。使う時には中を光の信号が行き交うため光るからライトファイバーで、使わないと光らないからダークファイバーという。 ダークネットは、元々、2011年に枯渇したとされるIPアドレス(IPv4)のうち、配布されていながら実際にはホストが割り当てられていないアドレス、つまり使われていないアドレス群を指す言葉だった。 このアドレスに向けてパケットが送信さ
こんにちは、技術部の遠藤(@mametter)です。フルタイム Ruby コミッタとして、クックパッドにあたらしく入社しました。よろしくお願いします。 最近、Ruby や RubyGems の脆弱性を発見して、その結果セキュリティリリースにつながるということを経験しました。どういう動機でどのように脆弱性を発見したか、どのように通報したか、などについてまとめてみます。Ruby の脆弱性を見つけたけどどうしよう、という人の参考になれば幸いです。 HackerOne について HackerOne という脆弱性情報の通報と公開のためのプラットフォームをご存知でしょうか。 OSS にとって脆弱性情報の管理は面倒なものです。脆弱性の通報を秘密裏に受け付け、関係者だけで議論しなければなりません。そのため、通常のバグトラッカとは別のコミュニケーションチャンネルを用意する必要があります。 そこで Hacke
2017/9/2 OWASP Kansai ローカルチャプターミーティング やられ教材サーバ(OWASP BWA)を用いた、OWASP ZAPの簡単な使い方紹介
概要 curlでhttps通信したときに、そういえばhttps通信ってどういう仕組みだったっけー忘れたーと思ったのでいろいろ思い出してみたので簡単にめもめも。 登場人物 認証局(CA) サーバー クライアント いろいろ用語 SSL 米ネットスケープ社が開発 TLS SSLが普及しだした時にIETFがSSLを元にしてTLSとして標準仕様にする SSLが先に普及したので、TLSのことをSSLと表記したりSSL/TLSと併記したりする サーバー証明書 証明書データをCAの秘密鍵でハッシュ化された署名が含まれている サーバーの公開鍵が含まれている。 認証局(CA) 電子商取引事業者などに、暗号通信などで必要となるデジタル証明書を発行する機関 CA証明書 ブラウザには最初っから入っている。CAの公開鍵が含まれている クライアント 主にブラウザなど ブラウザには主要な認証局の証明書(公開鍵)が登録され
見ず知らずの他人同士が、リーズナブルな計算量で、秘密の通信を行うためには、公開鍵暗号と秘密鍵暗号を組み合わせる必要があります。 この暗号の組み合わせのことを「暗号スイート」と呼びます。 OpenSSLには、多くの暗号スイートが用意されています。どの暗号スイートを選べばいいのか、迷ってしまうと思います。 そして、暗号スイート全体としての暗号強度は、公開鍵の強度も関係してきます。 ここでは、総当たり攻撃の耐性を基準に、暗号スイートと公開鍵の決め方を説明していきます。 以下、私の独断と偏見ですが、なぜGoogleやFacebookが、ECDHE(256bit)-ECDSA(256bit)-AES(128bit)の暗号スイートを使用するのか、ご理解いただけると思います。 併せて、Apache Webサーバ(httpd)のECDHEのビット数の変更方法(P-256, P-386)も、説明しています。
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
NginxでHTTPS:ゼロから始めてSSLの評価をA+にするまで Part 2 – 設定、Ciphersuite、パフォーマンス 今日のインターネットの世界では、一般的な静的Webサイトも含め、 全てのWebサイト に、強固で安全なHTTPSのセットアップが必要となります。この記事は、Nginxセキュリティをどのようにセットアップするのかに関するシリーズのパート2です。 パート1 は、Webサーバに有効な署名証明書をセットアップする話で終了しました。しかしこれには、最適な設定とは言い難い、デフォルトのNginxの設定を使用していました。 この記事を読み終えれば、SSL Labsのレポートで、A+の評価を獲得できる安全なHTTPSの設定ができます。それだけでなく、追加でいくつかの微調整も行い、パフォーマンスそしてUXも向上させていきます。 ここに掲載した記述やコードの抜粋の他にも、すぐに使
Disclaimer 本エントリーは、この夏 blackhat usa 2016で行われる予定の講演「NONCE-DISRESPECTING ADVERSARIES: PRACTICAL FORGERY ATTACKS ON GCM IN TLS」 のネタバレを含んでいます。現地で直接聞く方は読まないよう気をつけて下さい。 0. 短いまとめ 今回は短めにと思ったのですが、やっぱりそれなりの分量でした。なので短いまとめを書いておきます。 4千万以上のサイト対してAES-GCM使ったTLS通信の初期ベクトル(IV)データのサーベイが行われ、7万程のサイトでIVの値が再利用される可能性があることがわかりました。IVが再利用された場合、AES-GCMの安全性は致命的な影響を受けます。IVの再利用が判明した幾つか実装から既に脆弱性のアナウンスが出ています。 IVが再利用された場合、現実的にHTTPS
前方秘匿性(forward secrecy)とは、以下のような性質を指します。 公開鍵暗号の秘密鍵のように、比較的長期に渡って使われる鍵が漏えいしたときでも、それまで通信していた暗号文が解読されないという性質 鍵が漏れることも想定せよ――クラウド時代における「楕円曲線暗号」の必然性 - @IT 鍵が攻撃者や諜報機関など第三者の知るところとなった場合でも、それまで通信していた暗号文が解読されないようにしないといけない、という考え方とともに、最近 HTTPS を利用するウェブサイトにおいても導入が求められるようになってきた概念です。 前方秘匿性を満たすウェブサイトの設定方法については、TLSの暗号化方式をECDH_RSAあるいはECDHE_RSAに設定すれば良い、と述べている文献が多いです。 ですが、ほとんどのウェブサーバにおいて、それは誤りです。 なぜか。 通信を暗号化する鍵(セッション鍵)
先日のng-mtg#4 AngularJS 勉強会でLTしようと思ったけど申し込みが間に合わなかったのでブログに書きます。 先月リリースされたAngularJS 1.2はセキュリティがんばってる的なことを聞いたので、セキュリティ周りの仕組みを調べてみました。 お題は以下です。 CSRF JSON CSP (Content Security Policy) Escaping CSRF ユニークなトークンをHTTPリクエストに載せてサーバーでチェックする対応が世の中では主流(最近はカスタムヘッダのチェックによる対策も) AngularJSでは、XSRF-TOKEN Cookieにトークンが載っていると、$httpを使ったHTTPリクエストのヘッダに自動的にX-XSRF-TOKENヘッダーが付く。 XSRF-TOKEN CookieはもちろんNot HttpOnlyで。 Angular界ではCS
Enterprise x HTML5 Web Application Conference 2014の発表資料です。Read less
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く