死にゆくアンチウイルスへの祈りSecurity meets Machine Learning 第1回キックオフミーティング https://connpass.com/event/62844/ 発表資料
CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして - Mercari Engineering Blog
本日コーポレートサイトでお知らせした通り、Web版のメルカリにおいて一部のお客さまの個人情報が他者から閲覧できる状態になっていたことが判明しました。原因はすでに判明して修正が完了しております。また、個人情報を閲覧された可能性のあるお客さまには、メルカリ事務局より、メルカリ内の個別メッセージにてご連絡させていただきました。 お客さまの大切な個人情報をお預かりしているにも関わらず、このような事態に至り、深くお詫びを申し上げます。 本エントリでは技術的観点から詳細をお伝えさせていただきます。 2017年6月27日 CDNのキャッシュの動作について、CDNプロバイダと仕様について確認し検証を行いました。その結果一部記述に実際と異なる箇所があり、加筆修正いたしました。 概要 メルカリWeb版のコンテンツキャッシュをしているCDNのプロバイダ切り替えを行いました。 その際本来キャッシュされるべきでない
Struts2が危険である理由
はじめに 2017年3月、Struts2にまたしても新たな脆弱性(S2-045、S2-046)が見つかり、複数のウェブサイトにおいて情報漏洩等の被害が発生しました。筆者は2014年4月（およそ3年前）に「例えば、Strutsを避ける」という記事を書きましたが、今読み返してみると「やや調査不足の状態で書いてしまったな」と感じる点もあります。今回、良いタイミングなのでもう一度Struts2のセキュリティについてざっとまとめてみたいと思います。 なぜJavaなのにリモートからの任意のコード実行(いわゆるRCE)が可能なのか Struts2はJavaアプリケーションであり、Java製のアプリケーションサーバ上で動作します。Javaはいわゆるコンパイル型の言語であるため、通常はランタイムにおいて任意のコードを実行することはできず、RCEは難しいはずです。 JavaのウェブアプリケーションでRCEが成
例えば、Strutsを避ける
はじめに 筆者は10年以上ウェブアプリケーション開発を主な業務とするJavaプログラマであったにも関わらず、Strutsについてはこれまでずっと食わず嫌いでした。初期のStrutsは「XMLだらけで効率が悪そう」というイメージが強かったためです。最近はRuby on Rails等の影響を受けCoC(convention over configuration)を採り入れ、XML地獄もだいぶ解消したようです。 StrutsはJavaアプリケーションらしくない種類（任意のコード実行等）の脆弱性を連発することでも知られており、最近は我々の提供するSaaS型WAFサービス、Scutum(スキュータム)のお客様からも頻繁にStrutsについての問い合わせを受けるようになりました。また、去年見つかった任意のコード実行の脆弱性では、脆弱性の公表後すぐにPoCが出回り実際に攻撃が発生するなど、悪い意味で注目
単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
In some of the feedback I have gotten on the openID Connect spec, the statement is made that Connect is too complicated. That OAuth 2.0 is all you need to do authentication. Many point to Identity Pro… 英語読みたくないという人のために簡単に解説すると… OAuth 2.0 の implicit flow を使って「認証」をしようとすると、とっても大きな穴が開きます。 カット＆ペーストアタックが可能だからです。 OAuth 認証？は、図１のような流れになります。 図１ OAuth 認証？の流れ 一見、問題なさそうに見えます。しかし、それはすべてのサイトが「良いサイト」ならばです。 Site_A
サイバー犯罪捜査官を辞めた顛末など - ninolog
もの凄く簡潔に言ってしまうと、上司からのパワハラ+仕事内容です。 目標として夢見て10年、受験を決意し足掛け5年、 2015年冬の試験合格し、某県警のサイバー犯罪捜査官として、2016年春より働いておりました。 しかし、実際入ってみると、サイバーとは名ばかりであり、他の事案対応が95%弱を占め、 IT技術知識を活用するような機会は全くと言っていいほどありませんでした。 まぁそれだけなら全然納得して働いていたのですが、、、 では、退職を決意したもう一つの要因であるパワハラとは、 ★パワハラ具体例 1. コピーを取ってこい、と手渡された書類をコピーして持っていたところ、 俺のコピーしたかった書類と違う、お前は仕事の何を見ていたんだ、帰れ と怒鳴り散らす (最終的に私は帰ったのですが、もいっこ上の上司から呼び出され、私が悪いとのことで謝罪させられました) エスパーじゃなくてすいません、と謝れば良
ハッシュと暗号は違うぞ！ / Do not confuse hashes and ciphers.
PHP勉強会#110での発表資料です。
【初心者向け基本解説】Linuxのウィルスとその対策方法
Linuxは基本的に「ウィルス」いわゆる、「マルウェア」に感染しにくいという話はよく聞く。 しかし、実際には完全に安全なOSなどというものはありえない。Linuxを使っていても気をつけた方がいいに決まっている。 このページではLinuxのウィルス対策の初歩の初歩をお伝えする。 Linuxとウィルス Linuxは基本的に「ウィルス」に感染しにくいと言われているのは、次の２つの理由からだ。 クライアントでの利用の場合Windowsとくらべシェア率が圧倒的に低いため狙われにくい パーミッションという概念のもと一般ユーザはシステムに書き込みができない、権限が厳格に管理されている。 しかしリスクが全くないというわけではない。実際、数は少ないが主にトロイの木馬が存在する。これらは脆弱性を放置したり、ユーザが意図しないうちにうっかりインストールしてしまった場合が多いだろう。 特にクロスプラットホームなア
ハッシュ衝突でTLSを破るSLOTH攻撃(CVE-2015-7575)とは何か - ぼちぼち日記
0. 簡単なSLOTH攻撃のまとめ 最初に簡単なまとめを書いておきます。長文になりそうなので、読むのが大変な方はここだけ見ておいてください。 MD5ハッシュは既に安全ではなく、証明書の署名方式での利用は停止されていたが、後方互換のためハンドシェイクデータの署名方式にRSA-MD5が今でも利用できるTLS実装が幾つか存在していた(Firefox NSS, Java等)。 先週、INRIAグループからハッシュ衝突を利用して実際にTLSを破る攻撃(SLOTH)が公開された。それを受け、いくつかの実装でRSA-MD5を完全に利用不能にする修正が行われた(CVE-2015-7575)。 SLOTHでは、SHA1やTLS、IKE、SSHに対する攻撃についても評価を行い、幾つかは全く現実的に不可能なレベルではないことが示された。MD5とSHA-1でTLSハンドシェイクの完全性を担保しているTLS1.0/
PHPのJSON HashDosに関する注意喚起
4年前にHashDos（Hash Collision Attack）に関する効率的な攻撃方法が28C3にて公開され、PHPを含む主要言語がこの攻撃の影響を受けるため対策を実施しました。しかし、PHP以外の言語が、ハッシュが衝突するデータを予測困難にする対策をとったのに対して、PHPは、GET/POST/COOKIE等の入力データの個数を制限するという対症療法を実施したため、PHPにはHashDosに対する攻撃経路がまだ残っているということは、一部の技術者には知られていました。例えば、以下の様なつぶやきにも見ることができます。 だって、 hashdos 脆弱性の時、 Python とかの言語が、外部入力をハッシュに入れるときに衝突を狙えないように対策したのに、phpだけPOST処理で対策したからね？ json を受け取るような口もってるphpアプリのほとんどがhashdos残ってるんじゃない
Neverbleed - RSAの秘密鍵演算を別プロセスに分離する話
機能毎にプロセスを分割し、それらを別個の権限のもとで実行することで、脆弱性があった場合の影響を抑え込むというのは、一定以上の規模をもつプログラムでは、しばしば見られるデザインパターンです。 qmailは、そのような設計がなされたメール配送デーモンとして名高いですし、OpenSSHもまた、認証プロセスと通信プロセスを分離することで、外部との通信を担当するコードにバグがあったとしても、ルート権限が奪われないように設計されています（参照: Privilege Separated OpenSSH）。 一方で、OpenSSLにはそのような権限分離は実装されていません。Heartbleedの際にサーバの秘密鍵が漏洩したのも、秘密鍵の取り扱いと、その他の通信の取り扱いを同一のメモリ空間の中で行っていたからだと考えることができます。 ないのなら、自分で作ればいいじゃない…ということで作りました。それが、N
UTF-7 XSS Cheat Sheet
Countermeasures against XSS with UTF-7 are: Specify charset clearly (HTTP header is recommended) Don't place the text attacker can control before <meta> Specify recognizable charset name by browser. For more information about UTF-7 trick, see "Cross-site scripthing with UTF-7". These XSS patterns are tested on IE6 and IE7. Yosuke HASEGAWA <hasegawa@openmya.hacker.jp> Last modified: 2008-01
『証明書を無料で発行、HTTPSの導入を支援する「Let's Encrypt」』は何に使え、何に使えないのか - いろいろやってみるにっき
やっと、ついに、誰もが無料でHTTPSを使えるようになる！…MozillaやEFFが共同プロジェクトを立ち上げ - TechCrunchだが、ブコメ欄で「フィッシングサイトが見分けられなくなる」と勘違いしている向きがあるようなので、ちょっと書いておく。 このLet's Encryptだが、Let’s Encrypt: Delivering SSL/TLS Everywhereに説明が書かれている。そもそも上のTechCrunchの記事ではLet's Encryptがどういうものか分からない。この記事では何ができて何ができないかを書いていないし。 TechCrunchの記事はオレが見た時点(2014/11/20 5:00)ですごいブクマ数(792ユーザ)なんだけど、本体の説明のブクマ数は4ユーザ、オレがブックマークしたので5ユーザである。ちょっと調べてからコメントすればいいのに。 下記のほう
sshのポートをデフォルトの22/tcpから変えるべきか論争に、終止符を打ちました - ろば電子が詰まつてゐる
また間が開きましたが、すみだセキュリティ勉強会2015#2を開催しました。発表していただいた@inaz2さん、@yasulibさん、ありがとうございました。当日の発表資料は上記の勉強会ブログからリンクしています。 今回の私の発表は、「攻撃を『隠す』・攻撃から『隠れる』」。ポートスキャンをするとsshが100個現れる「ssh分身の術」がメイン(?)です。 当初は、パケットヘッダやプロトコルのすき間にメッセージを隠したり、ファイルを隠すなども考えていたのですが……。あまりに盛りだくさんになりそうだったので、「ポートスキャンをいかに隠れて実行するか・ポートスキャンからどうやって隠れるか」と、ポートスキャンとnmapに絞って発表しました。 発表資料 私の発表資料は以下です。 (PDF)攻撃を「隠す」、攻撃から「隠れる」 発表ノート付きなのでPDFです。以下、落穂ひろいなど。 スキャンするポート数と
五島夕夏がセキュリティのプロ 徳丸浩先生に一日密着！今すぐ使えるテクニックを盗んできました | NO MORE 情報漏えい
こんにちは、五島夕夏です！ 普段はフリーランスとしてイラストレーターやモデルのお仕事をしている私ですが、今日はNO MORE 情報漏えいプロジェクトの一員として、一日インタビュアーに挑戦します！ 突然ですが皆さんは、毎日の生活の中で「セキュリティ」についてどれくらい気をつけていることがありますか？ 私もTwitterやFacebookをよく利用しますし、お仕事もメールで受けています。PCを使う機会も多いので情報の管理には気をつけなきゃと思っているのですが、「具体的に何をどう気をつければいいのかわからない！」という人は私だけではないはずです。 ということで今回は、セキュリティのプロフェッショナルと呼ばれる徳丸 浩（とくまる ひろし）先生に密着取材！ プロがどんなところに気をつけているのか、私たちの生活にも活かせそうなテクニックを盗んできたいと思います！ 徳丸 浩（とくまる ひろし）先生 HA
TLS暗号設定ガイドライン 安全なウェブサイトのために（暗号設定対策編） | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
「TLS暗号設定ガイドライン」は、TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするためのガイドラインです。「様々な利用上の判断材料も加味した合理的な根拠」を重視して、TLS通信での実現すべき安全性と必要となる相互接続性とのトレードオフを考慮した3つの設定基準（「高セキュリティ型」「推奨セキュリティ型」「セキュリティ例外型」）を設けており、各々の設定基準に対応して、TLSサーバで設定すべき具体的な要求設定（「遵守項目」と「推奨項目」）を決めております。 本ガイドラインは安全なウェブサイトの作り方とともに適切な暗号設定をする資料の一つとしてお使いいただけます。 なお、本ガイドラインは、暗号技術評価プロジェクトCRYPTRECで作成されました。 「TLS暗号設定ガイドライン」の内容 1章と2章は、本ガイドラインの目的やSSL/TLSについての技術的な基礎知識を
Mozillaの報奨金制度で100万円ほど稼いだ話
This document summarizes Content Security Policy (CSP), a browser feature that helps mitigate cross-site scripting and other attacks. It discusses CSP's directives for controlling resource loading, browser support, syntax, and violation reporting. It also notes potential issues with abuse of CSP violation reports if not properly validated and formatted on the server-side.
glibcのgethostbyname関数に存在するCVE-2015-0235(GHOST)脆弱性について - ブログ - ワルブリックス株式会社
glibcのgethostbyname系関数に脆弱性の原因となるバグが発見されCVE-2015-0235(GHOST)と命名されたようです。放置した場合は相当多くのアプリケーションがこの脆弱性の影響を受けることが予想されます。 glibcは libcのGNUバージョンです。libcはアプリケーションではなく、事実上全てのアプリケーションが利用しているライブラリです。OSの中ではカーネルに次いで重要な部分と言えます。Linuxシステムでは(ことサーバー用途においては)例外なく glibcが使われています。 この glibcに含まれる gethostbyname系関数の実装に 2000年頃から存在したバグが今になって発見され、CVE-2015-0235 通称 GHOSTと命名されました。ネットワークで何らかの通信を行うアプリケーションは必ず※この関数を使用します。 ※追記: 名前解決をサポート
Node.js Security Tips
This is a republished blog post by Gergely Nemeth from RisingStack. They do Full Stack Javascript Development and Consulting. Gergely loves contributing to open-source projects like node-restify, organizing conferences, DevOps, Microservices and cycling. You can find his original article here. Node.js is getting more and more mature, no doubt - despite this, not a lot of security guidelines are ou
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DeNA Engineering - DeNAエンジニアのポータルサイト
