Travis CIでGitHub Personal access tokensが漏れないようにする
2017-05-09 漏れていた人はメールで通知が来ていると思いますが、Travis CIのログ上にGitHubのTokenが漏れていたケースがあるという話がありました。 (漏れていたTokenはGitHub側で既にrevokeされていると思います。またメールに漏れている一覧が載ってるはず) The Travis CI Blog: Security Advisory: Secured Environment Variables これ自体はTravis CIのバグではなくて、ユーザーが書いたデプロイスクリプトなどのツール側のバグによってGitHubのTokenなどsecretな環境変数がログ上に出ている話です。 Travis CIのログはPublicで誰でも見ることができるので、標準出力にTokenが露出していると問題があります。 どのようなケースでGitHubのTokenが標準出力に出てし
SHAttered で Git の SHA-1 ハッシュを衝突させられるか試す - 知らないけどきっとそう。
https://shattered.it/ のリリースを受けて、Git において、違うファイルをコミットしたにも関わらず、それらのコミットを参照する SHA-1 ハッシュが同じである状態を実現できるかを試しました。 同じ SHA-1 ハッシュを持つ PDF ファイルで可能か https://shattered.it/ で公開されている、SHA-1 ハッシュが同じ PDF ファイルを、それぞれ空のレポジトリにコミットします。 $ wget https://shattered.it/static/shattered-1.pdf https://shattered.it/static/shattered-2.pdf $ diff shattered-1.pdf shattered-2.pdf Binary files shattered-1.pdf and shattered-2.pdf dif
CVE-2016-7401 CSRF protection bypass on a site with Google Analytics の解説
gistfile1.md CVE-2016-7401 https://www.djangoproject.com/weblog/2016/sep/26/security-releases/ https://hackerone.com/reports/26647 pythonのcookie parserが ; 以外もpairsの区切り文字として解釈するので、google analyticsのreferrer経由でsetされるcookieを使ってCSRF tokenを上書き可能だったという問題。 django側でcookie parser自前で実装、python本体は直ってないようだ https://github.com/django/django/commit/d1bc980db1c0fffd6d60677e62f70beadb9fe64a 多くのcookie parserは、pairsの区
Typosquatting programming language package managers
Edit: It seems that the blog post and the thesis caused quite some interest. Please contact me under the following mail address: admin [|[at]|] incolumitas [[|dot|]] com In this blog post, it is demonstrated how 17000 computers were forced to execute arbitrary code by typosquatting programming language packages/libraries 50% of these installations were conducted with administrative rights Even hig
aeas44 — CentOS 7 の Nginx への Let's Encrypt の導入
CentOS 7 の Nginx への Let’s Encrypt の導入 この記事は「 How To Secure Nginx with Let’s Encrypt on CentOS 7 」の翻訳です。 はじめに (Introduction) Let’s Encrypt は TLS/SSL 証明書の入手とインストールを簡素化する方法を提供する新しい認証局です。 letsencrypt というソフトウェアを使い、Let’s Encrypt の設定に必要なほぼ全ての作業を自動化できます。まだベータ版ですが、Apache ウェブサーバでは、証明書の入手とインストールの手順が完全に自動化されていますが、いずれのウェブサーバであってもマニュアルで簡単に無料の証明書を入手することができます。 本記事では、Let’s Encrypt を使って SSL 証明書を取得する方法と、それを CentOS 7
Electronでアプリを書く場合は、気合いと根性でXSSを発生させないようにしなければならない。 - 葉っぱ日記
そのうちもう少しきちんと書きますが、とりあえず時間がないので結論だけ書くと、タイトルが全てでElectronでアプリを書く場合は気合いと根性でXSSを発生させないようにしなければならない。 これまでWebアプリケーション上でXSSが存在したとしても、影響範囲はそのWebアプリケーションの中に留まるので、Webアプリケーションの提供側がそれを許容するのであればXSSの存在に目をつむることもできた。しかし、ElectronアプリでDOM-based XSSが一か所でも発生すると、(おそらく)確実に任意コード実行へとつながり、利用者のPCの(そのユーザー権限での)全機能が攻撃者によって利用できる。 そのため、Electronでアプリケーションを作成する開発者は気合いと根性でXSSを完全につぶさなければならない。 nodeIntegration:falseやContent-Security-Pol
qpstudy 2015.11.14 一歩先を行くインフラエンジニアに知ってほしいSSL/TLS
インフラエンジニアの方向けに、SSL/TLSとは何か、また証明書入手のポイント、HTTPS設定のポイントについて、最新の動向を踏まえて紹介します。また、最後の方で勉強会主催者のリクエストでおまけがあります(^^;Read less
sshのポートをデフォルトの22/tcpから変えるべきか論争に、終止符を打ちました - ろば電子が詰まつてゐる
また間が開きましたが、すみだセキュリティ勉強会2015#2を開催しました。発表していただいた@inaz2さん、@yasulibさん、ありがとうございました。当日の発表資料は上記の勉強会ブログからリンクしています。 今回の私の発表は、「攻撃を『隠す』・攻撃から『隠れる』」。ポートスキャンをするとsshが100個現れる「ssh分身の術」がメイン(?)です。 当初は、パケットヘッダやプロトコルのすき間にメッセージを隠したり、ファイルを隠すなども考えていたのですが……。あまりに盛りだくさんになりそうだったので、「ポートスキャンをいかに隠れて実行するか・ポートスキャンからどうやって隠れるか」と、ポートスキャンとnmapに絞って発表しました。 発表資料 私の発表資料は以下です。 (PDF)攻撃を「隠す」、攻撃から「隠れる」 発表ノート付きなのでPDFです。以下、落穂ひろいなど。 スキャンするポート数と
OpenSSLの脆弱性CVE-2015-1793について - ロードバランスすだちくん
シンジです。続報です。（前回の記事） 新たに正式なアナウンスがありましたので、各種発表の一部から要約してお伝えします。 脆弱性について証明書系の攻撃にて、中間者攻撃を受ける可能性 緊急度高いとされています。 影響度影響度は低いと考えます。 AWSの各種サービスには、事実上影響無しHTTPS/FTPSなどSSL証明書を使用していない場合は影響なしAmazon Linuxはリポジトリを更新済みで適用可能AWSのサービスで対象があるものの、順次対応される為、ユーザー影響は無し対象範囲2015/6/11以降の比較的新しいOpenSSLにしか影響がないUbuntu 15.04 (Vivid Vervet)（訂正します、ご指摘ありがとうございます）, Amazon Linux等該当のバージョンは1.0.2c1.0.2b1.0.1n1.0.1o対処方法影響を受けるバージョンの1.0.2系は1.0.2dへ
CMS四天王のバリデーション状況を調査したところ意外な結果になった
バリデーションでSQLインジェクション攻撃をブロックしないCMSが多い ログインIDにおける典型的なSQLインジェクション攻撃として、'OR 1=1# をバリデーションがブロックするかどうかを確認しました。ログインIDとして許容される文字を見る限り、WordPress、Joomla、Drupalはブロックしそうですが、結果は下記の通りです。 WordPress: ブロックしない Joomla: ブロックする Drupal: ブロックしない MovableType: ブロックしない ということで、意外なことに、バリデーションでSQLインジェクション攻撃を止めるのはJoomlaのみという結果でした。 ログインIDにヌルバイトや改行が使えるCMSがある テストをしていてもっともびっくりしたことの一つがこれです。JoomlaとMovableTypeはヌルバイトや改行など制御文字がログインIDとして
2015年3月に発生したGithubへのDoS攻撃についてまとめてみた - piyolog
Githubが同社サービスに対してDoS攻撃が行われていることを発表しました。一連のDoS攻撃はGreatfire.orgに対して行われているものと考えられ、ここではGreatFire.orgに関係するDoS攻撃の情報をまとめます。 公式発表 GreatFire.org 2015年3月19日 We are under attack 2015年3月25日 (PDF) Using Baidu 百度 to steer millions of computers to launch denial of service attacks Github 公式Blog 2015年3月28日 Large Scale DDoS Attack on github.com · GitHub Github 公式Twitter The attack has ramped up again, and we're evo
ウェブアプリケーションを開発しながら、手軽に脆弱性検査する方法
Software WebSecurity ウェブアプリケーションを開発しながら、手軽に脆弱性検査する方法※当サイトにはプロモーションが含まれています。 以前、OWASP ZAP に追加された attack mode の概要 というエントリを書きましたが、このATTACK modeを使った簡単なセキュリティ検査の手順をメモしておきます。この機能を使えば、ウェブアプリケーションの開発中にZAPが勝手に脆弱性スキャンしてくれます。 ※ この機能が追加される バージョン 2.4 はまだリリースされていないのですが、こちら から ZAP Weekly をダウンロードすれば試すことができます。 概要基本的には、ウェブアプリケーション開発時にウェブブラウザのプロキシとして ZAP を指定おくだけです。この時、ZAP 側で コンテキストというものを設定して、ATTACK mode にしておけば、アクセスし
ES6時代におけるWeb開発者とセキュリティ業界の乖離
Developers Summit 2015講演資料 新世代「JavaScriptコントロール」が登場 ― 新「Wijmo(ウィジモ)」の実力 ― http://event.shoeisha.jp/devsumi/20150219/session/659/
ApacheのAddHandlerはセキュリティ上の懸念から使用すべきではない - このブログはURLが変更になりました
元ネタはこちら。 Apache AddHandler madness all over the place Gentoo Bug 538822 どういうことか 次のような指定は危険である。 AddHandler php5-script .php この時に指定される.phpはファイル名の末尾である必要はない。例えば、 aaa.php.html bbb.php.pngなどもphp5-scriptとして解釈されてしまうのだ。これは.XXX.YYYと複数の拡張子が書かれた場合、.XXXと.YYYもAddHandlerの対象となることが原因。 ちなみに次のような場合にはphp5-scriptとして解釈されない。 ccc.php_foo (.php_fooとして解釈されるため) ddd.php_bar.html (.php_barと.htmlとして解釈されるため)実はこのことはApacheのドキュメン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TBD/Shibuya.XSS techtalk #8
TLS徹底演習
HTTPoxy migitation · Issue #3422 · psf/requests
CookieのDomain属性は *指定しない* が一番安全
[PDF] Electronの倒し方
agilecatcloud.com
