The Three R’s of Enterprise Security: Rotate, Repave, and Repair
In the last 10 years, I’ve had the privilege of working on cloud security at Microsoft, Google, and Pivotal. Most recently at Pivotal, I’ve worked closely with some of the most forward-looking enterprises in the world. All of them want to deliver applications at a faster pace, and they are willing to try new tools, techniques, and processes to get there. I’ve observed another common trait — securi
JOSE (Javascript Object Signing and Encryption) is a Bad Standard That Everyone Should Avoid - Paragon Initiative Enterprises Blog
The latest information from the team that develops cryptographically secure PHP software. Is Your Cryptography Reliable? Our team specializes in studying real world cryptography implementations to assure their correctness and security. Why You Want to Hire Our Company Contact Us No Way, JOSE! Javascript Object Signing and Encryption is a Bad Standard That Everyone Should Avoid March 14, 2017 7:18
GMOメディアでのリスト型アカウントハッキング対策 | GMOメディア エンジニアブログ
こんにちは、セキュリティ担当の色川です。 今やサイバー攻撃の主流の１つとなった「リスト型アカウントハッキング」について、弊社における状況やこれまでに行ってきた対策・対応などを紹介します。 リスト型アカウントハッキング（リスト型攻撃）とは他社サイトから流出したログイン情報（IDとパスワードの組み合わせ）を使い、不正なログインを試みる攻撃手法です。「パスワードリスト攻撃」とか「不正ログイン攻撃」などとも呼ばれています。（本稿では以降「リスト型攻撃」と表記します。） 他社サイトのログイン情報なので、IDが存在しなかったりパスワードが違ったりしてほとんどは失敗に終わるのですが、流出元サイトと同じID・パスワードで登録している利用者がいるとログインされてしまいます。複数のサイトで同じID・パスワードを使い回す利用者が多いため、効率のよい攻撃手法となっているようです。 GMOメディアにおける状況弊社で
iframe sandbox は万能ではない - 葉っぱ日記
HTML5で導入されたiframe要素のsandbox属性は、そのiframe内のコンテンツに対しJavaScriptの実行を始め様々な制約を課すことでセキュリティの向上に役立つ機能である。例えば、以下のように指定されたiframeでは、iframe内からformのsubmitなどはできるが、iframe内でのJavaScriptの実行やtarget=_blankなどによってウィンドウを開くことなどは禁止される。 <iframe sandbox="allow-forms" src="..."></iframe> sandbox属性に明示的に allow-scripts という値を指定しない限りはiframe内では直接的にはJavaScriptは実行できないが、かといってiframe内から間接的にJavaScriptを必ずしも実行させることが不可能かというとそうでもない。 sandbox属性
Electronでアプリを書く場合は、気合いと根性でXSSを発生させないようにしなければならない。 - 葉っぱ日記
そのうちもう少しきちんと書きますが、とりあえず時間がないので結論だけ書くと、タイトルが全てでElectronでアプリを書く場合は気合いと根性でXSSを発生させないようにしなければならない。 これまでWebアプリケーション上でXSSが存在したとしても、影響範囲はそのWebアプリケーションの中に留まるので、Webアプリケーションの提供側がそれを許容するのであればXSSの存在に目をつむることもできた。しかし、ElectronアプリでDOM-based XSSが一か所でも発生すると、(おそらく)確実に任意コード実行へとつながり、利用者のPCの(そのユーザー権限での)全機能が攻撃者によって利用できる。 そのため、Electronでアプリケーションを作成する開発者は気合いと根性でXSSを完全につぶさなければならない。 nodeIntegration:falseやContent-Security-Pol
CSS based Attack: Abusing unicode-range of @font-face
In this post, I would like to share about new CSS based attack with unicode-range descriptor of @font-face rule. Using this technique, an attacker can read page's text partially by CSS only. An attacker might use this technique in the following cases: - Browser's XSS filter bypass (e.g. XSS Auditor does not block <style> injection) - Only CSS injection is allowed in the target page As far as I kno
PHPのJSON HashDosに関する注意喚起
4年前にHashDos（Hash Collision Attack）に関する効率的な攻撃方法が28C3にて公開され、PHPを含む主要言語がこの攻撃の影響を受けるため対策を実施しました。しかし、PHP以外の言語が、ハッシュが衝突するデータを予測困難にする対策をとったのに対して、PHPは、GET/POST/COOKIE等の入力データの個数を制限するという対症療法を実施したため、PHPにはHashDosに対する攻撃経路がまだ残っているということは、一部の技術者には知られていました。例えば、以下の様なつぶやきにも見ることができます。 だって、 hashdos 脆弱性の時、 Python とかの言語が、外部入力をハッシュに入れるときに衝突を狙えないように対策したのに、phpだけPOST処理で対策したからね？ json を受け取るような口もってるphpアプリのほとんどがhashdos残ってるんじゃない
PHPにないセキュリティ機能
PHPカンファレンス関西2015での私のセッション「PHPに無いセキュリティ機能」のスライドです。 何が無いのか、知っていれば対応できます。 何が問題になっているのか、知っていれば対応できます。 セキュリティ対策は職人技敵（脆弱性対策をコード中に散りばめ、全体を把握しないと安全にできない作り方）ではなく、CERT/SANS/OWASPが推奨するセキュリティ対策を行い、エンジニアリング的（科学的、体系的な作り方）を行う方が簡単かつより安全、高品質なアプリケーションを作れます。 PDFをダウンロードしたい方はブログをご覧ください。 http://blog.ohgaki.net/missing-security-related-parts-of-phpRead less
TLS暗号設定ガイドライン 安全なウェブサイトのために（暗号設定対策編） | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
「TLS暗号設定ガイドライン」は、TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするためのガイドラインです。「様々な利用上の判断材料も加味した合理的な根拠」を重視して、TLS通信での実現すべき安全性と必要となる相互接続性とのトレードオフを考慮した3つの設定基準（「高セキュリティ型」「推奨セキュリティ型」「セキュリティ例外型」）を設けており、各々の設定基準に対応して、TLSサーバで設定すべき具体的な要求設定（「遵守項目」と「推奨項目」）を決めております。 本ガイドラインは安全なウェブサイトの作り方とともに適切な暗号設定をする資料の一つとしてお使いいただけます。 なお、本ガイドラインは、暗号技術評価プロジェクトCRYPTRECで作成されました。 「TLS暗号設定ガイドライン」の内容 1章と2章は、本ガイドラインの目的やSSL/TLSについての技術的な基礎知識を
Masato Kinugawa Security Blog: 第4期サイボウズラボユース成果報告会の発表資料を公開
実は昨年の夏、サイボウズラボユースという制度を利用させていただいて、3週間程度サイボウズラボのオフィスに出社していました。 サイボウズ・ラボ：人材募集：サイボウズ・ラボユース http://labs.cybozu.co.jp/recruit/youth.html 何をしていたかといいますと、@herumi さんや @takesako さんにご指導頂きながら、アセンブリ言語をずっと読んでいました。 XSSをはじめとするWebアプリケーションの脆弱性はそれなりに知っているつもりですが、バッファオーバーフローをはじめとするメモリ関連のバグは全然理解していませんでした。 これまでも、アプリケーションが偶然クラッシュするたび、そういった方面への関心がでてきて、アセンブリを読めば何かわかるのかなあと思って、読んではみるけど、無慈悲なバイナリの羅列に圧倒されるということを繰り返してきました。 ただ、アラ
クラウドを支えるこれからの暗号技術
SSII2021 [TS3] 機械学習のアノテーションにおける データ収集 〜 精度向上のための仕組み・倫理や社会性バイアス 〜SSII
glibc の脆弱性 CVE-2015-0235（通称：GHOST）についてまとめてみた - piyolog
2015年1月27日(現地時間) Qualysはglibc(GNU C Library)に脆弱性を発見し、情報を公開しました。ここでは関連情報をまとめます。(暫定まとめなので精度低め、網羅性無しです。。) (1) 脆弱性関連情報 Qualysが公開した脆弱性情報 The GHOST Vulnerability Qualys Security Advisory CVE-2015-0235 注意喚起 IPA (注意) libc の脆弱性対策について(CVE-2015-0235) 脆弱性の概要 glibcの__nss_hostname_digits_dots() にヒープバッファオーバーフローの脆弱性。 当該関数はglibcのgethostbyname()とgethostbyname2()から呼ばれている。 アプリケーションによっては、DoS、またはリモートから任意のコードが実行可能となる可能性
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://github.com/ChALkeR/notes/blob/master/Gathering-weak-npm-credentials.md
【やじうまWatch】「パスワードの定期変更をユーザーに求めるべきではない」……NISTの文書でついに明示へ
GitHub - dxa4481/Pastejacking: A demo of overriding what's in a person's clipboard
Code4Sec | LinkedIn
Sass を今すぐ実務で使おうよ！ « LINE Engineers' Blog
TechCrunch | Startup and Technology News
クラウド型Web脆弱性診断ツール「VAddy」
