第19回セキュリティさくらの資料（前半だけ）です。
HashDoS脆弱性との戦い！ Rubyコミッター・卜部昌平が明かすプログラム堅牢化のノウハウ 過去、HashDosの影響を受けたRuby。言語開発者はいかにしてこうした問題に対応してきたのでしょうか。コミッターである卜部氏の貴重な記録を公開します。 2011年の末頃、HashDoSという脆弱性が公表され、Rubyもこの影響を受けた。本稿の筆者である卜部昌平（うらべ・しょうへい／@shyouhei／以下、卜部）は、報告当初からRuby側のチームメンバーとしてプログラム本体の修正を担当した。以下はその記録である。言語開発者たちが普段どのようなことを考え、どういった技術を用いて開発やバグフィックスを行っているのか。その概要を知ってもらえれば幸いだ。 オブジェクト指向スクリプト言語 Ruby HashDoSの概要 なぜ約6年後の今、修正内容を公開するに至ったか？ 前史：すでに内包されていたリスク
この日記はPHP Advent Calendar 2017の25日目です。前回は@watanabejunyaさんの「PHPでニューラルネットワークを実装してみる」でした。 OWASP Top 10 2017が発表され、ウェブのセキュリティ業界がざわついています。というのも、2013年版までは入っていたCSRFが外され、以下の2つの脅威が選入されたからです。 A4 XML外部実体参照(XXE) A8 安全でないデシリアライゼーション これらのうち、「A8 安全でないデシリアライゼーション」については、過去に「安全でないデシリアライゼーション(Insecure Deserialization)入門」という記事を書いていますので、そちらを参照ください。 本稿では、XML外部実体参照（以下、XXEと表記）について説明します。 XXEとは XXEは、XMLデータを外部から受け取り解析する際に生じる脆
Key Reinstallation Attacks Breaking WPA2 by forcing nonce reuse Discovered by Mathy Vanhoef of imec-DistriNet, KU Leuven, 2017 Introduction We discovered serious weaknesses in WPA2, a protocol that secures all modern protected Wi-Fi networks. An attacker within range of a victim can exploit these weaknesses using key reinstallation attacks (KRACKs). Concretely, attackers can use this novel attack
PWA Study( https://web-study.connpass.com/event/65267/ ) で発表した資料です。
こんにちは KOBA789 です。前回に引き続き Capy のパズルタイプを突破するお話です。 Capy がより堅牢な CAPTCHA ソリューションにためには突破するためのアルゴリズムを公開することが重要だと考え、解説をするに至りました。 ちなみに今回紹介するアルゴリズムは前回の記事とはまったく別物です。今日の夕方頃、Capy に仕様変更があり、背景画像のバリエーションが増えたようです。前回紹介したアルゴリズムはそのような仕様変更でほぼ無効化されると思われます。しかし、今回紹介するアルゴリズムはそのような変更の影響を原理的に受けません。影響を受けない理由も考えて解説をお読みいただければと思います。 Capy とは 前回の記事では執筆時間の関係で端折ったのですが、今回は少しまともに解説をしておきましょう。 公式サイトより引用します。 Capyが提供する国際特許出願済のソリューションは、“セ
メルカリでCDNにキャッシュされるべきでないページがキャッシュされることにより個人情報の流出が発生してしまうインシデントがありました 自分は動的コンテンツをCDNで配信することにあまり積極的ではない立場だったのですが流出への反応を見るとCDNを利用しているサービスはかなり増えてきているようです 個人情報やユーザーのプライベートデータを決して流出しないようにしつつCDNを利用する方法を考えてみました CDN利用のメリット このふたつ 経路が最適化されレイテンシが小さくなる DDoS対策となる キャッシュされないようにする方法 Twitterで動的コンテンツもCDN通すの当たり前でしょーと言ってる人にリプしてきいてみました CDNとレスポンスヘッダで二重にキャッシュを無効化する キャッシュを細かくコントロールCDNを使う ホワイトリスト方式で特定のパスのみキャッシュを許可 ログインセッションを
本日コーポレートサイトでお知らせした通り、Web版のメルカリにおいて一部のお客さまの個人情報が他者から閲覧できる状態になっていたことが判明しました。原因はすでに判明して修正が完了しております。また、個人情報を閲覧された可能性のあるお客さまには、メルカリ事務局より、メルカリ内の個別メッセージにてご連絡させていただきました。 お客さまの大切な個人情報をお預かりしているにも関わらず、このような事態に至り、深くお詫びを申し上げます。 本エントリでは技術的観点から詳細をお伝えさせていただきます。 2017年6月27日 CDNのキャッシュの動作について、CDNプロバイダと仕様について確認し検証を行いました。その結果一部記述に実際と異なる箇所があり、加筆修正いたしました。 概要 メルカリWeb版のコンテンツキャッシュをしているCDNのプロバイダ切り替えを行いました。 その際本来キャッシュされるべきでない
エグゼクティブサマリ PHPMailerのリモートコード実行脆弱性CVE-2016-10033は、従来MTAとしてsendmailを用いる場合のみ影響があるとされていた。また、WordPressはPHPMailerをバンドルしているが、CVE-2016-10033によるWordPressに対するリモートコード実行攻撃はできないとされていた。しかし、MTAとしてExim4を用いる場合には、PHPMailer単体およびWordPress 4.6からのリモートコード実行が可能であることがわかったので報告する。 はじめに 昨年末に話題となったPHPMailerのリモートコード実行脆弱性CVE-2016-10033ですが、当初公表されていたPoCがsendmailコマンドの -X オプションを用いたものであったため、-X オプションのないMTA（postfix, qmail, exim4等）は直ちに
a.md Chrome ExtensionのLive HTTP Headersを調査した。Firefox用のものではない。Firefox用のものではない。 https://chrome.google.com/webstore/detail/live-http-headers/iaiioopjkcekapmldfgbebdclcnpgnlo 11/7追記 類似 or 同様の方法で難読化scriptを埋め込んでいる拡張機能が大量にあったため、Googleに報告済み。 https://twitter.com/bulkneets/status/795260268221636608 English version: https://translate.google.com/translate?sl=ja&tl=en&js=y&prev=_t&hl=ja&ie=UTF-8&u=https%3A%2F%
はじめに サーバ管理をしている身としては、 セキュリティ は常に付きまとう悪魔みたいなもので、このセキュリティに関しては何をどこまで頑張ればいいのか不透明な部分が多い。 脆弱性に関しては、CVEなど、毎日情報は入ってくるが、それがどのサーバの何に関連したものなのかなんていちいち調べてられないし、どの脆弱性がすぐに対応しなければいけないもので、どの脆弱性があとあと対応すればいいものなのかなんてわからない。 実際のところ、大きな話題になった脆弱性くらいしか緊急で対応してないという人は多いのではないかと思う。 そんな中、満を持して登場したのが vuls !! 各サーバの脆弱性情報を取得して、個々のサーバそれぞれでどんな脆弱性があり、どのくらいやばい脆弱性なのかを検知できるようになった！ 今回はこのvulsを紹介します。 Vulsとは 公式でロゴが発表されたので、差し替えました 公式ドキュメント:
LINE Developer Meetup in Fukuoka #16 http://connpass.com/event/38413/
by Eljay 中国最大級の認証局「沃通(WoSign)」がニセ証明書を発行していた問題で、ウェブブラウザの1つ・FirefoxがWoSignの証明書をブロックする方針を固めました。 WoSign and StartCom - Google Docs https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/ Firefox ready to block certificate authority that threatened Web security | Ars Technica http://arstechnica.com/security/2016/09/firefox-ready-to-block-certificate-authority-that-threatened-we
■ サブドメイン管理者が親ドメインの SSL 証明書を取得する _ 中国最大級の認証局「WoSign」がニセの証明書を発行していたことが判明。サブドメインの管理権限がある人が親ドメインの SSL 証明書が取得できちゃったんだって。この問題、他の CA でもあるんだよね、実は。 _ 具体的に言うと Let's Encrypt がそれ。 この記述。example.com ドメインの所有者かどうか判断する方法のひとつとして、_acme-challenge.example.com の TXT レコードに指定のトークンを記述せよ、というのが挙げられている。ということで、ユーザが自由にサブドメインを作れるサービス上で _acme-challenge というサブドメインを作成すれば親ドメインの証明書を発行してもらえる。今回の WoSign の件のように任意のサブドメインでいけるわけではなく、ラベルにアン
11. コードの差分から diff -r -u joomla-3.4.5/libraries/joomla/session/session.php joomla-3.4.6/libraries/joomla/session/session.php --- joomla-3.4.5/libraries/joomla/session/session.php 2015-10-21 17:48:16.000000000 +0900 +++ joomla-3.4.6/libraries/joomla/session/session.php 2015-12-14 14:42:12.000000000 +0900 - - // Check for clients browser - if (in_array('fix_browser', $this->_security) && isset($_SERV
外部から簡単にHTTP_PROXYという環境変数がセットでき、サーバ間通信や外部サイトと連携している場合に影響があるかもしれない脆弱性です。(HTTPoxy. CVE-2016-5385) PHPの場合はphp-fpm, mod_php, Guzzle4以上やいくつかのライブラリで影響あります。 対応方法は簡単です。 Apache側で対応する場合は、mod_headerを使える状況であれば、confファイルに下記の1行を追加。 RequestHeader unset Proxy FastCGIの場合は下記の1行を追加。 fastcgi_param HTTP_PROXY ""; Guzzleは6.2.1で対応されたようです。 Release 6.2.1 release · guzzle/guzzle · GitHub コミットログを見ると、CLIの時のみ、getenv('HTTP_PROXY
注意 本件記事ですが、私の不適切な行動（拾ったスクリプトを検証なく走らせる）が原因です。「dockerは（特に何もしなくとも）危険」との誤解を皆様に与えた点、ご迷惑をおかけいたしました。申し訳ございません。 拡散されている記事を削除するのはさらなる誤解を招きかねないと思いましたので、冒頭に注意を付記しております。以下の記事は、「自分が何してるかをきちんと検証できないとセキュリティホールを生み出す」という意味で参考にして頂ければ幸いです。 追記 Twitterやはてブで言及いただきました皆様、ありがとうございます。 本件はpullしてきたイメージが悪意ある開発者によるものかどうかにかぎらず、不適切な設定をしていると起こり得ます。 ※コメント欄に質問への回答という形で、私がそのときに走らせていたイメージの一覧を挙げておりますが、どのイメージも評判あるものだと思います。 皆様におかれましては「あ
■ eLTAXに反省なし 誤りを認めない告知文の捻出に3か月を費やしその間利用者を危険に晒す 3月14日の日記「治外法権のeLTAX、マルウェア幇助を繰り返す無能業者は責任追及されて廃業に追い込まれよ」から3か月近く経った今日、eLTAXが注意喚起を出しているとの情報が入り、なぜ今頃になって再び注意喚起をするのだろうかと首を傾げた。 ３ヶ月前の高木さんのblogの「署名済みActiveXコントロールのダウンロードを有効にする」eLTAXの件で、問題の対策して今日利用者向けにお知らせしているようです。https://t.co/Qk37l9cRMkhttps://t.co/epQvcdKiu5 — あさくら (@AkioAkioasakura) 2016年6月3日 よく見てみれば、あれ以来、何ら注意喚起を出していなかったのだ。つまり、これは再度の注意喚起などではなく、3か月経ってこれが初の「お
ImageTragickの脆弱性を利用されると、なにが起こるの？ImageMagickに、複数の深刻な脆弱性があることが発表されました。 これらの脆弱性はまとめて「ImageTragick」と呼ばれており、公式ページやロゴ、Twitterアカウントがつくられています。 https://imagetragick.com https://imagetragick.com/img/logo-medium.png https://twitter.com/ImageTragick RedHat系の場合は、以下のページに対応方法が書かれています。 https://access.redhat.com/security/vulnerabilities/2296071 Resolveタブを押すと、 Red Hat Enterprise Linux 6 & 7 と Red Hat Enterprise Lin
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
