ImageTragickの脆弱性を利用されると、なにが起こるの？
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
Electronのnodeモジュール読み込みの問題が修正された - 葉っぱ日記
昨年10月に報告した、Electron製アプリケーションを起動した際にアプリケーション外のnodeモジュールを読み込んで実行されてしまうという脆弱性が修正された。 JVN#00324715: Electron における Node モジュール読み込みに関する問題 正確には、修正は報告とほぼ同じタイミングにリリースされた v0.33.5 で修正されていたが、4月まで公表がずれ込んだようである。 Changelog: Don't add paths outside the app to Node module search paths in packaged app.Release electron v0.33.5 · electron/electron (https://github.com/electron/electron/releases/tag/v0.33.5) つまり、v0.33.5
安全で便利な Webhook を作る
安全で便利な Webhook を作る Tweet Webhook をご存知でしょうか。GitHub やその他のサービスで提供されているあの機能です。 今回は弊社の Komoju API で Webhook を提供する際に気づいた、webhook 実装上の注意点について書きます。 内部のサーバーへのアクセスを禁止する 一般的な Webhook はユーザーが送信先となる任意のURLを指定して、サービスはそこに対してPOSTリクエストを送信します。 このときに気をつけないといけないのは「そのURLがサービス内部のホストかどうか」を識別しなければならないということです。 たとえば localhost とか、内部 DNS のドメインとかです。このような宛先への Webhook 送信を許可してしまうと、本来は外部から隔離されてアクセスできないはずのサーバーに Webhook送信サーバー経由でアクセスで
横柄なパスワード – パスワード認証に関する改善策 | POSTD
パスワードにはうんざり。改善しましょう。 誰もが経験するあの瞬間。新しいサービスに登録し、パスワードを選んで入力する。でも、入れません。選んだパスワードは十分安全なはずなのに、使いたいサービスが独善的にそれを拒むのです。 記号、数字、大文字、小文字を少なくとも１つずつ使用しなければなりません。 小文字の長いパスワードの方がドルマークだらけの短いパスワードより安全だということを証明する、 XKCDの有名なコミック のことは忘れましょう。まず、あなたの主力パスワードが $$ICECREAM$$ だとします。アイスクリームは、恐ろしい人生の希望の灯火とも呼べるほどの大好物なので簡単に思い出せます。そして、このパスワードにはブートのための特殊文字が入っています。 残念なことに、 $$ICECREAM$$ には小文字と数字がないので、客観的に見れば安全ではありません。そこで、このサービスのためのパス
よくわかる認証と認可 | DevelopersIO
よく訓練されたアップル信者、都元です。「認証 認可」でググると保育園の話が山程出て来ます。が、今日は保育園の話ではありません。そちらを期待した方はごめんなさい。こちらからお帰りください。 さて、先日のDevelopers.IO 2016において、マイクロWebアプリケーションというテーマでお話させて頂きました。一言で言うと OAuth 2.0 と OpenID Connect 1.0 のお話だったのですが、これらを理解するにあたっては「認証」と「認可」をはっきりと別のものとしてクッキリと認識する必要があります。 まず、ざっくりとした理解 認証と認可は密接に絡み合っている一方で全く別の概念です。正直、理解は簡単ではないと思います。 まず「認証」は英語では Authentication と言います。長いので略して AuthN と書いたりすることもあります。意味としては 通信の相手が誰（何）であ
Electronでアプリを書く場合は、気合いと根性でXSSを発生させないようにしなければならない。 - 葉っぱ日記
そのうちもう少しきちんと書きますが、とりあえず時間がないので結論だけ書くと、タイトルが全てでElectronでアプリを書く場合は気合いと根性でXSSを発生させないようにしなければならない。 これまでWebアプリケーション上でXSSが存在したとしても、影響範囲はそのWebアプリケーションの中に留まるので、Webアプリケーションの提供側がそれを許容するのであればXSSの存在に目をつむることもできた。しかし、ElectronアプリでDOM-based XSSが一か所でも発生すると、(おそらく)確実に任意コード実行へとつながり、利用者のPCの(そのユーザー権限での)全機能が攻撃者によって利用できる。 そのため、Electronでアプリケーションを作成する開発者は気合いと根性でXSSを完全につぶさなければならない。 nodeIntegration:falseやContent-Security-Pol
nginxでDDoS対策をする方法
nginxでDDoS対策をするための方法を調べてみました。 いくつか方法が見つかったので、リンクをまとめてみました。あとで、色々試してみようと思います。 nginxをプロキシサーバとして利用して、バックエンドにアプリサーバを配置するような構成で使うので、外部から来たDDoSをnginxでブロックしてアプリサーバを守る。といったような用途になるかと思います。 もちろん、nginxが応答できるHTTPリクエストの範疇に収まらない攻撃は、その前段階でブロックしたり、他のサーバにアクセスを逃したりする必要があります。 DDoS攻撃に対するシンプルな戦略 | ツチノコブログ(http://tsuchinoko.dmmlabs.com/?p=611) さらに、こちらで紹介されているように、完璧に防ごうとすると青天井のコストが見えてしまったりするので、”どれくらいDDoSからの保護をするのか”を明確にル
サイト訪問者がcookieを切っていても追跡可能な手法が明らかに
by Andy Arthur ウェブサイトによる行動追跡を防ぐためにcookieを削除していても、そのユーザーが以前に訪れたサイトのドメインや履歴を知ることができる手法があると、研究者が発表しました。 Unpatched browser weaknesses can be exploited to track millions of Web users | Ars Technica http://arstechnica.com/security/2015/10/unpatched-browser-weaknesses-can-be-exploited-to-track-millions-of-web-users/ これは独立系研究者のYan Zhuさんが「ToorCon: San Diego 2015」の中で語ったもの。講演時の資料のPDFファイルが以下のツイートからダウンロード可能です。
PHPのJSON HashDosに関する注意喚起
4年前にHashDos（Hash Collision Attack）に関する効率的な攻撃方法が28C3にて公開され、PHPを含む主要言語がこの攻撃の影響を受けるため対策を実施しました。しかし、PHP以外の言語が、ハッシュが衝突するデータを予測困難にする対策をとったのに対して、PHPは、GET/POST/COOKIE等の入力データの個数を制限するという対症療法を実施したため、PHPにはHashDosに対する攻撃経路がまだ残っているということは、一部の技術者には知られていました。例えば、以下の様なつぶやきにも見ることができます。 だって、 hashdos 脆弱性の時、 Python とかの言語が、外部入力をハッシュに入れるときに衝突を狙えないように対策したのに、phpだけPOST処理で対策したからね？ json を受け取るような口もってるphpアプリのほとんどがhashdos残ってるんじゃない
マイナンバー歴44年の僕から一言
あなたのマイナンバーは届いたかな？ 実は僕、皆さんより一足先にマイナンバーを持っているんだ。なんと44年前からね。 ということで今回は"マイナンバーの先輩"として色々話させてもらいましょう。 もちろん、僕が持っているのはアメリカのものだから、正確にいうと「マイナンバー」ではない。アメリカの場合はSocial Security Number(社会保障番号、略してSSN)と呼ばれている。 考えてみれば英語で「マイナンバー」とは「私の番号」という意味。"Can I have your my number?"（あなたの私の番号を教えてください）は、結構ばかばかしいセンテンスとなってしまう。日本の役所の方々は英語でやり取りするときはどう対応するのかな？ 時は1936年、大恐慌の真っ最中だった。ニューディール政策の一環として発足した社会保障プログラムに合わせ、SSNは発行された。当時は年金の管理用だっ
AWS で不正アクセスされて凄い額の請求が来ていた件 - yoya's diary
情けない話ですが、自分の大チョンボで AWS の個人アカウントが第三者にアクセスされた結果 190万円相当のリソースが使われ、最終的に AWS さんに免除を頂きました。反省込みで本件のまとめを書きます。 自分が馬鹿を幾つも重ねた結果であって、AWS 自体は怖くないというのが伝われば幸いです はじめにまとめ S3 実験してた時に SECRET KEY を見える場所に貼っていた事があり、第三者がそれでアクセスし大量の高性能インスタンスを全力で回す (恐らくBitCoin採掘) AWS さんから不正アクセスの連絡があり、急いで ACCESS KEY 無効＆パスワード変更、インスタンス全停止、イメージ削除、ネットワーク削除 免除の承認フェーズを進めて、クレジットカードの引き落とし前に完了して助かる AWS さんのサポート AWS さんは最大限サポートしてくれました 承認フェーズが進まない時もあまり
AWS News Blog
Stop the CNAME chain struggle: Simplified management with Route 53 Resolver DNS Firewall Updated 2 May 2024: I removed the reference to Route53 Alias that was incorrectly referred as a chain Starting today, you can configure your DNS Firewall to automatically trust all domains in a resolution chain (such as aCNAMEor DNAMEchain). Let’s walk through this in nontechnical terms for those unfamiliar wi
「Apache Cordova」を使ったハイブリッドアプリケーションの脆弱性に関する調査
Apache Cordova は、Android/iOS の両環境で動作するハイブリッドアプリケーションを開発するためのフレームワークとして、アプリケーション開発者に利用されているものです。アプリケーションのマルチプラットフォーム対応を実現するための開発フレームワークは、今後もその利用が拡大すると考えられますが、セキュリティを考慮せずに利用した場合、アプリケーションに脆弱性が作り込まれ、ユーザをセキュリティ上の脅威にさらすことになりかねません。 本報告書は、Apache Cordova を使用してアプリケーションを開発した場合にどのような脆弱性が作り込まれうるかをアプリケーションの構成要素毎に調査・検討した結果をまとめたものです。Apache Cordova を既に利用してアプリケーションを開発している、あるいは今後の利用を検討している開発者の皆様にご一読いただき、アプリケーション開発にお
悲報 パスワードが記載された国勢調査の利用案内が無防備にポスティングされる事案が続出
出張中、平成27年国勢調査の「インターネット回答の利用案内」という封書を妻が受け取っていました。 そろそろ来る頃だと知っていたので、来た時にはきちんと「国勢調査員証」を確認するように言っていたのですが、我が家を担当されている調査員の方はしっかりとした方だったようで、自ら「国勢調査員証」を提示され封書を手渡されたとのこと。 ただ、この封書って中に調査対象者IDと初期パスワードを記載した用紙が入っているにも関わらず、封印されていないんですね。 用紙の下部には以下のように書いてあります。 ※この利用者情報は、配付された世帯でのみご使用ください。また、第三者に渡らないように取扱いなどには十分ご注意ください。 ※本誌は、セキュリティ確保のため、原則、再発行いたしません。 調査対象者ＩＤは、回答内容の確認や修正を行うための再ログインの際に必要となります。 このような注意喚起をするのであれば、IDやパス
sshのポートをデフォルトの22/tcpから変えるべきか論争に、終止符を打ちました - ろば電子が詰まつてゐる
また間が開きましたが、すみだセキュリティ勉強会2015#2を開催しました。発表していただいた@inaz2さん、@yasulibさん、ありがとうございました。当日の発表資料は上記の勉強会ブログからリンクしています。 今回の私の発表は、「攻撃を『隠す』・攻撃から『隠れる』」。ポートスキャンをするとsshが100個現れる「ssh分身の術」がメイン(?)です。 当初は、パケットヘッダやプロトコルのすき間にメッセージを隠したり、ファイルを隠すなども考えていたのですが……。あまりに盛りだくさんになりそうだったので、「ポートスキャンをいかに隠れて実行するか・ポートスキャンからどうやって隠れるか」と、ポートスキャンとnmapに絞って発表しました。 発表資料 私の発表資料は以下です。 (PDF)攻撃を「隠す」、攻撃から「隠れる」 発表ノート付きなのでPDFです。以下、落穂ひろいなど。 スキャンするポート数と
「line://msg/text/～ 」からのLINEメッセージ送信の仕様が危険なので注意
LINEにて、「line://msg/text/」で始まるURLが拡散されています。このURLは、「指定された文章を送信するためのURL」で、「LINEで送る」ボタンの中身として利用されているURLなのですが、このURLから送信に至るまでの画面遷移で、送信内容の確認画面が無い仕様のため、自分が何を送信するのかを確認できないまま送信してしまい、意図と反した投稿を行ってしまう危険性があります。 何を送信するのかが表示されないまま先に進む画面の途中で止める判断ができれば問題にはならないのですが、LINEのユーザー層と、実際送信してしまった人が多数見つかること、そして、「次こそ送信内容の確認画面が出るだろう」と考えて先に進む人（←以前の仕様では表示された）、などなどを考慮すると、今後悪用された場合に大きな危険を招きそうな仕様であると感じました。 今回ユーザーが意図せず送信してしまうのは「ずっと前か
HTTPS 化する Web をどう考えるか - Block Rockin’ Codes
Update 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。 2015/5/8: 構成を一部修正しました。 Intro 4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。 Deprecating Non-Secure HTTP | Mozilla Security Blog エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 本エントリも同じく CC BY-SA 3.0 とします。 Deprecating Non-Secure HTTP 原文: Deprecating Non-Secure HTTP 今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。 HTTPS が Web を前進させる手段である
プログラマー（ソース改ざん箇所の改修） - 仕事依頼 - SOHOビレッジ
ファーストサーバーでコーポレートサイトを運用していますが、 サーバー会社より下記連絡がありました。 ・不正アクセスがありソースを一部改ざんされている可能性が高い ・迷惑メールがプログラム送信されている 上記理由によりサイト表示を止められております。 ファイル改修後、再度アップロードをする様にとの指示がありました。 つきましては改ざん箇所の抽出、改修が可能な方に修正を実施して頂き再度アップしたいと考えております。 ご対応が可能な方は大凡の納期と概算御見積をご連絡ください。 宜しくお願い致します。 レステル柴田
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[PDF] Electronの倒し方
https://jp.techcrunch.com/2016/01/05/20160104is-the-password-dead-the-future-of-web-and-mobile-authentication/
