【Java -> C】C言語でJavaの「SecureRandom」は実現できるのか?

投稿者: Anonymous 始めて質問させて頂きます。 質問は題名通りですが、概要を説明させて頂きます。 Javaの「SecureRandom」で生成した乱数を 暗号化した値で認証する処理が必要となり、 暗号を使って通信する相手はJavaのアプリ。 こちらはマイコン(C言語)となっています。 同じ言語で設計していれば悩む必要のない話ですが、 相手は既に設計完了済みで変更できず、かつこちらも 開発環境的にC以外では開発ができません。 とりあえず、Javaの「Java.security.SecureRandom」と 同じ乱数をCで実現可能なのか現在調査中ですが、 これといってヒントになるような資料が見当たりません。 恐れ入りますが、何かご存知の方がいらっしゃいましたら ご教授頂けると幸いです。宜しくお願いします。 解決 既に「暗号論的に安全な乱数」を送ってくる側があるのに 認証する側で「同じ乱数」が得られるはずも無いんですがどういう意味でしょうか? (同じ乱数を得ることができるのなら暗号論的に安全ではない) マイコン側で暗号論的に安全な乱数を生成する、のであれば 何らかのハードウエアが使えるはずなのでそれに頼るしかないです。 A/D 変換器の熱雑音とかが簡単です。 それなりの電気回路をあらかじめ盛り込んでおく必要がありますけど。 回答者: Anonymous

compromised の日本語訳は?

投稿者: Anonymous https://security.stackexchange.com/ などセキュリティ系の情報を読んでいると、しきりに compromised という単語が出てきますが、(例: compromised hardware, compromised OS, etc) compromise された状態とはどういう状態でしょうか。また、日本語に訳すとしたら何になりますか? 解決 (クラッカーなどに)侵入された (ウィルスなどに)感染した という意味ではないでしょうか。 英辞郎などには「易感染性」のような意味も出ていますから、医学用語由来かもしれませんね。 易感染性という言葉から類推すると、脆弱なだけでまだ侵入されていない場合にも使うのかもしれません。 しかし少なくとも、「侵入された可能性がかなりある」くらいにはマズい状況に使われている気がします。 OP 追記: 医学用語における易感染性とは、免疫が落ちて通常なんでもない微生物にでも感染してしまう状態です。そのような状態に陥ってしまった患者のことを compomised host と呼びます。 なので、ウイルス、クラッカーに侵入された(可能性がある)状態に陥ってしまった、 が一番適切な翻訳だと思われます。 回答者: Anonymous

UACの確認ダイアログで画面を暗転させる理由は?

投稿者: Anonymous Windows Vista から導入されたUAC(ユーザーアクセス制御)では、特権の必要な操作を実行するときに確認のダイアログが表示されます。この際デフォルトでは画面全体が暗転します。 「デスクトップを暗転しない」という設定もありますが、推奨されませんと注意書きがあります。 セキュリティリスクが高まるのだろうと思いますが、暗転なしでは可能で、暗転ありでは不可能な攻撃というのは、具体的にはどのようなものなのでしょうか。 また、同じような暗転を自分のアプリケーションに実装することもできるのでしょうか。 ※単純に画面を暗くするという意味の「暗転」ではなく、UACの設定における「デスクトップを暗転しない」のリスクを知りたいという意図でした。ですからセキュアデスクトップへの切り替えも含みます。 解決 あの暗転は「セキュリティで保護されたデスクトップ」への切り替えです。 Windowsの仕様では非表示のデスクトップからキーイベントのメッセージをフックすることはできませんので、デスクトップを切り替えることでキーロガーを回避しているのだと思います。 回答者: Anonymous

「Superfish」に対する脆弱性の検出方法と削除方法を知りたい。

投稿者: Anonymous StackExchange の Facebook タイムラインにも登場するなど、話題になっていたので参考になるかと思い以下の StackExchange のポストとその Accept された回答を訳しました。 How to detect if I am vulnerable to “Superfish,” and how to remove it? ご参考: Superfish について、以下で出てくる声明や脆弱性についての日本語ニュース記事: nikkeibp : http://itpro.nikkeibp.co.jp/atcl/news/15/022000616/ 訳は以下から サイト( security.stackexchange.com ) では、Superfishのセキュリティリスクについてはもう議論されました。 そこでの内容は、だれかの接続のビットデータを改変するものは全て悪い(bad) という話に見うけられます。TLS接続を改変するのなら、それは悪(evil) だとも。 自分が Superfish に対して脆弱であると測定する方法を教えてください。 Lenovo は、Superfish について (すでに血だらけの手で捕まえられた後に) もう無効にしたという声明を出しました。 そうはいっても私はもうLenovoを信用できません。システムドライブの初期化(format c:)以外に Superfish を完全に削除する方法はありませんか? Edit: 上にリンクで貼った Lenovo の声明には、今はSuperfish がインストールされているかもしれないモデルの一覧が載っています。…(Continue Reading)

iOSアプリにおけるmBaaS使用時のApplicationKey、ClientKey(Secret)のセキュリティについて

投稿者: Anonymous mBaaSを使ったiOSアプリを作る際、AppDelegate.swiftに下記のようなコードを書くと思います。(※例はNiftyCloudMobileBackend) NCMB.setApplicationKey(“XXXXXXX”, clientKey: “YYYYYYYY”) このキーが漏れてしまうと、情報の更新が外部から可能になってしまうと思います。 例えば、git管理の話ならばKeyを別のファイルに区切ってgitignoreしてしまえばよいと思いますが、アプリのリリース時にこの部分はどうすべきでしょうか? monacaやJSの場合、herokuにClientKeyを置いて回避する方法(http://blog.mb.cloud.nifty.com/?p=7410) 等が見つかりましたが、iOSのクライアントのみでできる対策はどのようなものがありますでしょうか? 知見のある方はご教示の程、宜しくお願い致します。 解決 クライアント側のみでできる対策としては難読化があります。 例えば、以下のライブラリを使って文字列を難読化することができます。 https://github.com/UrbanApps/UAObfuscatedString // Password という文字列をUAObfuscatedStringをつかって表現する let password = “P”.a.s.s.w.o.r.d このようにすることによって、バイナリ上に連続した文字列としてパスワードが現れることを防ぎ、stringsコマンドなどの簡易的な方法ではパスワードを抜き出すことができなくなります。 (※ これはあくまで簡易的な対策です。stringsより本格的な解析をされるとパスワードが抜き出されてしまう可能性があります) 回答者: Anonymous

JavaScript&HTMLクライアント利用時の、クライアントの正当性を担保する方法について

投稿者: Anonymous バックエンドAPIサーバーと通信するクライアントを、JavaScript&HTMLで作成しようとしています。 バックエンドで「正しいクライアントからのリクエストか否か」を調べるためには、クライアントに専用の秘密の文字列を埋め込んでおき、それをリクエストパラメータまたはヘッダに含めて送信するのが一般的なのではないかと思います。 しかし、JavaScript&HTMLでその手法を採用した場合、ユーザは秘密の文字列に容易にアクセスすることができてしまいます。 それにより、(知識のあるユーザであれば)バックエンドAPIを利用した野良サイトを作るなどして自由にAPIを使うことが可能です。 JavaScript&HTMLのクライアントで、「正しいクライアントからのリクエストか否か」を調べるセキュアな方法はありますでしょうか。 解決 ありません。いかなる対策も、改竄をしようとするユーザが解読打破できます。 質問内容からクライアント側がPCであるとします。その環境では、ユーザから隠される情報、ユーザが変更のできない情報はありません。あなたが心血を注ぐことで、ユーザーによるプログラム改竄コストを上げることはできますが、本質的な部分であなたの目的は達成不可能です。 効果的な対策があるとすれは、それはサーバサイドで、クライアントの挙動をチェックをすることでしょう。怪しい挙動・リクエストのパターンを定義し、そのパターンを検知した場合に認証トークンの無効化、もしくは一定時間の ban とします。 回答者: Anonymous

insecure_private_key の置き換えについて

投稿者: Anonymous vagrantがバージョン1.7以降になってから 初回のbox作成・起動時にinsecure_private_key を 置き換えていると説明されていますが、具体的に何がどうなっているのでしょうか。 質問の経緯は以下のとおりです。 現在ubuntu 15.04でvagrant 1.7.2を使っています。 以前、ホストOSにwindows7を使っていた頃、 vagrantが1.7になってからのことですが、boxを新規作成させた後、 teraterm等からログインできなくなるという現象が起こり、 それについてはネットの情報を参考にVagrantfileに config.ssh.insert_key = false という1文を挿入することでさしあたりの問題は解決しました。 いくつかの説明を読んでいると、どうやらvagrantが1.7になってからの仕様変更で、 vagrantの提供する共通公開鍵を持つboxを使ったゲストOS作成時では それに対応するホスト側の秘密鍵(~/.vagrant.d/insecure_private_key)が 自動的に置き換えられてしまう……らしい……みたいなことになっていると なんとなく理解していました。 ところが今日、OSをubuntuに変えてから初めて、 vagrant init chef/centos-6.6 とした後に、Vagrantfileを全く編集しない状態でも vagrant ssh とすると、普通にログインできてしまいました。 これは以前、windows7でvagrant 1.7を使っていた時には teratermでエラーになっていたはずでした。 これはもしかして1.7.2では何らかのバグが治ったのだろうか? くらいに考え、でも気になるので、試しに ~/.vagrant.d/insecure_private_keyと https://github.com/mitchellh/vagrant/blob/master/keys/ に置いてある、vagrantという名前のファイル (共通公開鍵に対応する秘密鍵のはず) の中身を比較してみると、中身が全く同じです。 ランダムに置き換えられた秘密鍵に変わるんじゃなかったのか?? と、これまでの理解か、確認の方法、またはその両方が間違っているらしいと 気が付いた次第。 元々公開鍵暗号の仕組みも、秘密鍵を持つ人だけが公開鍵を使って暗号を解ける、 くらいの理解しかなかったので、そもそもそれが間違いなのかもしれませんが、 結局、vagrant が初回のbox作成・起動時にinsecure_private_keyを 置き換えていると説明されているのは、具体的に何がどうなっているのでしょうか。 愚問かと思いますが、教えていただけると嬉しいです。 よろしくお願いします。 解決 自己解決しました。 確かに現在のvagrantはゲストOSの初回起動時にホストOS側の鍵情報を自動で変更し、ゲストOSと暗号の再調整を行っています。 ただし、その置換後に使う秘密鍵ファイルの場所はvagrant…(Continue Reading)

DDoSを予告されたときに、すぐにできる緩和策はありますか?

投稿者: Anonymous 自らの運営するサービスに対するDDoS攻撃を予告された場合、突然攻撃されることと比較して良い点はありますか? 例えば、「1時間後に攻撃する」と予告された場合、1時間でできるなんらかの緩和策はあるのでしょうか。 また、30日後の攻撃を予告された場合はどうでしょうか。 解決 サービスの規模にもよりますが、1時間あれば、 CloudflareやMicrosoft Azureが提供するDDoS Protectionを導入できるでしょう。 AkamaiやCloudflareにはDDoSの攻撃中に使える緊急サポートがあります。予告されただけでは対象になるか不明ですが、連絡を取ってみるのはアリです。 AWSなどスケールが容易な環境であれば、サーバ側のリソースを一時的に増強することも可能です。そうでない環境でも、30日あればいくらかの増強はできるのではないかな、と思います。 とはいえ、実際のDDoSの予告には脅しだけのものも多いですし、攻撃の規模は始まってからでないとわからないところがあります。 回答者: Anonymous

github 初回 clone 時の authenticity を、正しくとりあつかう方法は?

投稿者: Anonymous Github から Git で ssh で初回 clone するときには、「authenticity が確認できない」といったようなメッセージがでます。 The authenticity of host ‘github.com (xxx.yyy.zzz.www)’ can’t be established. これは個人で開発している場合には何も考えずに yes を一回だけ押せば、後は大体なんとかなります。 自動化して環境デプロイをするときには、これはセキュリティ的にきちんと取り扱った方がいいのだろうな、と思います。また、このメッセージが発生することにより、自動化スクリプトが正しく働かない場合などがあったりして、やっかいです。 質問 サーバーをたくさんプロヴィジョニングする前提で、初回に出てくるこれを正しく自動化して取り扱いたいです。どのような設定ないしコマンドを実行するのが、セキュリティ的に推奨なのでしょうか。 追記 アドレス形式は、 git:// の方式のものを想定しています。 解決 初めての接続先だから相手の公開鍵をちゃんと確認しましょう、ただ生の公開鍵だと目視確認するには長すぎるから短縮した(ハッシュ化した)fingerprintで代替して良いことにしましょう、 というのがそのメッセージの意図するところかと思います。 従って、あらかじめ公開鍵がわかっているのならそれを取得して $HOME/.ssh/known_hosts に記載しておいてやれば良いのではないでしょうか。 ssh-keyscan -H github.com >> ~/.ssh/known_hosts 参考: ssh(1) VERIFYING HOST KEYS Public key fingerprint – Wikipedia (GitHub’s SSH key fingerprints…(Continue Reading)

awsのセキュリティグループにセキュリティグループを関連付けるとどうなりますか?

投稿者: Anonymous AWSのセキュリティグループにセキュリティグループを関連付けることができるのですが、 この場合どういう動作になるかご存知の方がいらっしゃいましたらご教授お願いできますでしょうか。 よろしくお願いします。 解決 セキュリティグループでは、接続元をネットワークアドレスで許可することができますが、その替わりに他のセキュリティグループで許可することもできます。 例えば、ELB、Webサーバー、DBサーバーのような階層があったとして、それぞれ、カッコ内のセキュリティグループで起動するものとします。 ELBインスタンス x N (ELB_Group) ↓ Webサーバーインスタンス x N (Web_Group) ↓ RDSインスタンス (DB_Group) Webサーバーインスタンスから RDSインスタンスへのアクセスを許可する場合、セキュリティグループ:DB_Group に、送信元を Web_Group とするインバウンドルールを設定します。 送信元をネットワークアドレスで許可するよりも、より正確なアクセス制御ができます。 同様に、ELBインスタンスから Webサーバーインスタンスへのアクセスを許可する場合、セキュリティグループ:Web_Group に、送信元を ELB_Group とするインバウンドルールを設定します。 なお、VPC が出来る前(Classic EC2)は、サブネットを利用できなかったため、送信元をセキュリティグループとしてアクセス制御する仕組みが必要でした。 という表面上の動作ではなく、内部的な動作の質問でしょうか? 回答者: Anonymous

OAuth2のclient_secretは、漏れると何がマズいか? また、どうやって隠すか?

投稿者: Anonymous Google APIを使ってツールを作成しました。Webアプリのようなものではなく、ローカルで動くPythonスクリプトで、REST APIにアクセスしています。 これの公開を考えていますが、現状、client_id, client_secretが丸見えです。 そこで、質問です。 1. OAuth2のclient_secretが漏れると、誰(例:API公開者であるGoogle, APIを使ったアプリの開発者である私, アプリの利用者, それ以外の第三者)にとって、どのようなリスクがありますか? 2. もしclient_secretを漏らすべきでないとすれば、どのようにして隠すのがセオリーでしょう? 解決 OAuth2のclient_secretが漏れると、誰(例:API公開者であるGoogle, APIを使ったアプリの開発者である私, アプリの利用者, それ以外の第三者)にとって、どのようなリスクがありますか? OAuth2は「認可」のための仕様です。「あなた(ユーザ)に代わって、○○さん(が作ったプログラム)があなたの情報を扱うことになるが良いか?」という許可をユーザから得ることになります。つまり、そのユーザに対して、プログラムの作者を信用してもらうことが必要になってきます。 client_secretが漏れること、それはすなわち、別の誰かが「あなたの名前を語って」ユーザの情報を扱うことができるようになってしまう、ということを意味しています。ほとんどの場合、ユーザの情報は個人情報などを含む非常に大事な情報になりますので、client_secretの保護を怠った開発者は自分の名前を誰かに語られて不正にユーザ情報を収集され、ユーザ情報が悪用された結果、その責任が「client_secretの保護を怠った開発者」に降りかかってくる可能性が非常に高まると言うことができるかと思います。 もしclient_secretを漏らすべきでないとすれば、どのようにして隠すのがセオリーでしょう? 「ローカルで動くPythonスクリプト」を公開するのであれば、そのスクリプトにあなたが取得したclient_id及びclient_secretを書かない状態で公開するのが良いかと思います。そのスクリプトを使いたければ、自分でclient_idやclient_secretを取得して自己責任で使ってください、とすれば良いかと思います。 回答者: Anonymous

悪意のある javascript が実行できることは?

投稿者: Anonymous 話を簡単にするために、ブラウザ・ホストOSの脆弱性などはなかったと(考慮しないように)します。 悪意のある javascript を含むページを開いてしまった場合に、そのコード断片が実行可能なことは何になりますか? これも簡単のために、それは malicious-web.com という攻撃者独自のドメイン・サイトを閲覧してそこから実行されたとしています。 個人的にこれを聞こうと思った背景には、例えば以下のようなことが可能なのではないかと考えたからです。 LAN 内部でのみアクセス可能なドメイン・ホストがあり、そこに対してデータを GET して、それを malicious-web.com/storage にむかって POST する。 これが可能であったならば、「悪意のある javascript を実行すると、その client が実行されているパソコンからアクセス可能な http 通信リソースすべてを、攻撃者は取得・操作できる」と言えそうです。 では、ここから自分は理解できていないのですが、その取得できるリソースは http 通信だけでしょうか? 他の TCP/UDP 系の通信はどうでしょう? ローカルのファイルシステムはどうでしょう。 malicious-web.com ドメインのクッキーは(もちろん)取得できそうですが、その他のサイトのものはどうなのでしょうか? など。 解決 LAN 内部でのみアクセス可能なドメイン・ホストがあり、そこに対してデータを GET して、それを malicious-web.com/storage にむかって POST する。 ほとんどのAPIが同一オリジンポリシーに従って設計されているため、そういったことは不可能です。たとえば攻撃者ドメインのページがLAN内ドメインのページを <iframe> で指定しても、描画はされますがその <iframe>内の window や document にはアクセスできません。 ただし、<img src=…> や…(Continue Reading)

gzip_types を限定すれば BRACH・CRIME 攻撃を受ける心配はない?

投稿者: Anonymous 最新のRails、Nginxで、SSLを使用しています。BREACH, CRIMEのセキュリティ的な問題から、Nginxのgzipをオフにしているのですが、gzip_types で text/css や application/javascript だけなら、利用しても大丈夫なのでしょうか? 解決 それらは、「ユーザーが制御可能な文字列」と「秘密の文字列」の両方がレスポンスに含まれる時に、二つの文字列が一致するかどうかで圧縮後のサイズが変化することを利用した攻撃です。 このような挙動を示すかどうかが重要であり、レスポンスの形式は関係ありません。動的に生成する場合、 CSS や Javascript であっても同様に注意が必要です。 もしあなたが「このMIMEタイプは動的に生成することはない」と言い切れるのであれば、そのような設定でも構わないように思います。 参考 SSL暗号を無効化する仕組み – BREACH, CRIME, etc | yohgaki’s blog 回答者: Anonymous

脆弱性対策におけるhtmlspecialchars()の使用箇所について

投稿者: Anonymous PHPでスクリプト挿入攻撃やXSS対策として、サイタイズのためにhtmlspecialchars()を使うことがあると思いますが、使用する際の詳細が気になったので質問します。具体的には以下の2点です: サニタイズ関数を適用するタイミングについて 【ユーザからの入力時】【HTMLへの出力時】【その中間】の3パターンが考えられますが、ベストなのはどれでしょうか?GET・POSTパラメータの処理と、その出力がほぼ同時に行われる場合では違いが顕在化しませんが、そうでないより一般的な場合に注意する点が知りたいです。 『パーフェクトPHP』330・334頁によると「出力時にエスケープ」とだけ書いてありますが、それに関連する詳細の記述やサンプルコードがないため背景知識があってそうなるのか、それとも単なる著者の思いつきなのか判断できません。 【ユーザからの入力時】にサニタイズしてしまうと、HTML出力以外でサニタイズ前の文字列が必要になった際にhtmlspecialchars_decode()等で元に戻す必要があるため、やはり【HTMLへの出力時】がベストなのでしょうか? htmlspecialchars()とhtmlentities()の使い分けについて いずれも第2引数にENT_QUOTESを指定すると思いますが、サニタイズ目的に限る場合、htmlspecialchars()で十分でしょうか。それともhtmlentities()まで使用する必要があるでしょうか? get_html_translation_table()で変換される文字の違いは分かるのですが、どこまでやればサニタイズ目的で十分なのかよく分かりません。 以上詳しい方いらっしゃいましたら、ご教示ください。 解決 ドメインレベルでの対策を行っていない場合 「出力時にエスケープ」 1択です。他の選択肢は考えられません。著者の思いつきではなく、ここ数年万人によって当たり前のように言われ続けていることです。 【ユーザからの入力時】にサニタイズしてしまうと、HTML出力以外でサニタイズ前の文字列が必要になった際にhtmlspecialchars_decode()等で元に戻す必要があるため、やはり【HTMLへの出力時】がベストなのでしょうか? その通りですね。他にも エスケープ忘れ や 多重エスケープ といったミスを防ぐ意図もあります。「格納時にエスケープ」という手段を採用している某日本の大手Q&Aサイトは、今までに私が確認できただけでXSS脆弱性を3回に加えて多重エスケープも同じ回数ぐらい発生させてしまっています。後者に関しては今も放置されている箇所があります。 また、エスケープされた状態だと 「n文字以内でトリミングする」という処理を書くのが困難 になります。上で挙げたQ&Aサイトや某短文投稿サイトでもこれに関して、エンティティ表記されている部分が途中でぶった切られる問題も発生していたりします。 ドメインレベルでの対策を行い、ユーザの自由なHTML記述を許可している場合 はてなブログやFC2ブログなどでは、 「ログインした状態で何かするページ」 にはHTML記述を一切認めず、 「記事を表示するだけのページ」 ではHTMLの使用を認めています。 そもそもエスケープしていないことになりますね。 記事を表示しているページ上で直接コメント等が出来ない ことに気付くと思います。はてなブログはインラインフレーム埋め込み、FC2ブログは別ページへの移動となります。 どちらを選ぶべきか セキュリティに関して十分な知識があり、ドメインを用意できるならこちらの選択肢もアリです。但し基本的にはやはり前者の「出力時にエスケープ」の方が選択されるべきです。 ENT_QUOTES の必要性 シングルクオートで括られた属性内に表示する際には必須です。但し一般的にはダブルクオートで括る方が主流なので、デフォルトの ENT_COMPAT が必ずしも悪いというわけではありません。思考停止したように ENT_QUOTES を採用する必要はないです。 但し… 文字セットのデフォルト値がPHPのバージョンによって異なるという大きな変更が過去にあった 使用頻度が多い割に関数名自体が長い という背景も踏まえて、どうせなら function h($str) { return htmlspecialchars($str, ENT_QUOTES, ‘UTF-8’); } という関数を作ってしまっておいてそれを流用する方が良いでしょう。…(Continue Reading)

AWSのRDSの暗号化のメリットについて

投稿者: Anonymous Amazon Web Services(AWS)で提供されているAmazon Relational Database Service(RDS)の暗号化について質問です。 RDSでは、基本的に「リソースの暗号化」と「接続の暗号化」が存在するようですが、まずはリソースの暗号化について質問させて下さい。 RDSインスタンスのリソースの暗号化を有効化した場合、具体的にRDSインスタンス、自動バックアップ、リードレプリカ、スナップショットのリソースが暗号化されるようですが、自分以外のユーザがAWSコンソールにアクセスできるようなことが無い場合(IAMなど)、これらのストレージを暗号化するメリットを感じられなかったのですが、どうなのでしょうか?リソースの暗号化を利用する場合、m3.medium以上のインスタンスを利用しなければいけないため、コスト的なデメリットを感じています。 次に、接続の暗号化についてですが、VPCのPrivate SubnetにRDSを設置しPublic Subnetに設置されたEC2インスタンスのアプリケーションからのみRDSにアクセスできるようにした場合、SSLによる通信の暗号化を行ったところで、誰もその通信を傍受することができないと思うのですが、こちらの認識についても誤りがありましたら、ご指摘していただきたいです。 SSL暗号化は、セキュリティ上の利点を提供する一方、SSL暗号化がかなりの計算処理を必要とするオペレーションで、データベース接続の待ち時間を増加させることがあるという記述がAmazonのドキュメントにございましたので、できれば無効化したいと思っています。 しかし「リソースの暗号化」と「接続の暗号化」を無効にした場合、上記の認識でセキュリティ意識に対する穴がないという自信を持てませんでしたので質問させていただきました。 よろしくお願いいたします。 解決 AWSのデータセンター(DC)内部に悪意のある人間が紛れ込んだ場合への対応、としては穴があることになります。 一例なのですが、バックアップの入ったディスク(またはイメージ)が流出した、EC2インスタンスが繋がるハブに特殊な機器を接続され流れるパケットを盗み見られた、そういったケースへの対応です。DC外部からでも、実装時には未知だった脆弱性により、そういう内容が漏れることが考えられます。 もちろんサービスの内容、保存するデータの重要度によっては「そういうことならしかたないよね」で済む場合もあるでしょう。逆に言うと、データの重要度が高ければ、できたはずの暗号化を実施していなかったことが責任上の大きな問題になる場合もあります。 いずれにせよ、「取れない/見れないから大丈夫」ではなく、「万が一見られても大丈夫」という視点が、暗号化を考える上では肝要です。加えてセキュリティ対策では、問題が発生した時にどれだけの損失・責任が発生するかが重要なファクターになります。特に コスト にはそういうリスクも織り込むべきでしょう。 回答者: Anonymous

PHPのプリペアードステートメントのセキュリティについて

投稿者: Anonymous 以下のようなプリペアードステートメントを作りました。 $ps=$db->prepare(“SELECT id, name, time FROM comment WHERE user = $area ORDER BY $order $desc”); defaultでは $area=”1 or 1=1″; $order=’time’; $desc=””; が入っており、SELECT id, name, time FROM comment WHERE user = 1 or 1=1 ORDER BY time;が実行されます。 質問1 WHERE部分とORDER部分において、:t_timeのようにbindParamを実行しようと思ったのですが、 上手くいきませんでした。普通に変数にしたら出来たのですが、これは普通のやり方でしょうか? 質問2 $area, $order, $descをGET送信で受け取る場合、SQLインジェクションなどのセキュリティ上の問題は発生するのでしょうか。 自分で試したところ、問題なさそうだったのですが。。。 解決 こんにちは。 回答1 普通に変数にしたら出来たのですが、これは普通のやり方でしょうか? 普通ではありません。$areaは引用符で囲っていないということは、数値でしょうか。その場合、例えば以下のようにします。数値の場合は、バインドする値をintなどにキャストするほうがいいです。 $ps=$db->prepare(“SELECT id, name, time…(Continue Reading)

クライアント側のJavascriptにトークン等を渡したい時、どうやってHTMLに埋め込むべきか

投稿者: Anonymous サーバーサイドプログラムが生成した値をJavascriptに渡す際、直接scriptタグ内に変数を出力すべきか、<head>の<meta>タグのcontentとして持たせるべきか決めかねています。 具体例として、CSRF対策用のトークンを使って非同期通信などでデータを取得する際、最初は次のようにしてデータをHTMLに直接出力していました。 <script> var config = { api_url: ‘<?php echo $apiUrl;?>’, token: ‘<?php echo $csrfToken;?>’, }; </script> 複数のリンクされたJSファイルからこの情報を利用するため、グローバル変数を定義する必要がありました。(ブラウザ要件によりconstは使えません) しかし使用しているフレームワーク(Laravel)の公式ドキュメントによるとこのような変数を用いず、<meta>のcontentを使うよう説明がありました。 <meta name=”csrf-token” content=”<?php echo $token;?>”> // jQueryでの使用例 <script> $.ajaxSetup({ headers: { ‘X-CSRF-TOKEN’: $(‘meta[name=”csrf-token”]’).attr(‘content’) } }); </script> たしかにこちらの方法のほうが書き換えられる心配が少ないのでグローバル変数を使うよりも綺麗にかけるので良いのですが、Javascript の定数を宣言するために積極的に meta タグを利用すべきなのでしょうか? 似たものとして例を挙げると APIサーバーのURL、認証用のアプリケーションIDやワンタイムパスワード、ログイン中のユーザーIDなどがあると思います。これらの値を複数のJSファイルで使いまわす可能性がある場合どのような形で定義すべきかのルールや傾向などありましたら教えて下さい。 解決 うろ覚えですが「このデータはこれで送信しないとエラー扱いになる」というような 厳密な規定の仕様は無かったような気がします… metaタグや平文のjavascriptはそれぞれデータの持ち方に大きな違いが有ります。 「javascriptの変数だから」という切り分け方よりも その受け渡したい「データがどういった属性や性質等を持つか」によって 適合しやすい方法へ切り分けるべきかと思います。 平文のjavascriptへの埋め込みはjavascriptでしか使わないデータや 数式とかjavascriptの関数を埋め込むような使い方に向いています。 認証IDやトークン等は文字長が比較的少なく クライアント側javascript以外にサーバー側アプリケーションや ネットワーク間の機器(キャッシュサーバー等)も使用することが有ります。…(Continue Reading)

任意ユーザが投稿したzipファイルを安全にダウンロードするには?

投稿者: Anonymous 任意ユーザが投稿した(任意のプログラム系の)zipファイルを、PHPで安全にダウンロードする仕組みを作りたいのですが、注意すべきことは何ですか? HTML出力の場合は「特殊文字を HTML エンティティに変換」しますが、ダウンロードの場合に該当する処理はありますか? 例えば、zipファイル形式ではなく、個別ファイルでexe形式以外の拡張子のみokとすれば安全ですか? 解決 サーバーにアンチウイルスソフトをインストールしてアップロードしたコンテンツに対して実行する方法があります。 定義ファイルも更新が必要になりますし、面倒なので、どうしても必要性がない限りはこういう機能は作らない方がいいです。 Linux用のオープンソースのアンチウイルスソフト http://www.clamav.net/ 単純にダウンロードの実装をしたいなら、以下のようにヘッダーを指定してください。 $filename = ‘download.zip’; $filepath = ‘/home/user/file.zip’; header(‘Content-Type: application/force-download’); header(‘Content-Length: ‘.filesize($filepath)); header(‘Content-Disposition: attachment; filename=”‘.$filename.'”‘); readfile($filepath); 回答者: Anonymous

ESET がインストールされた mac で、 ウェブアプリに [::1] のアドレスで接続できないのは何故?

投稿者: Anonymous セキュリティソフトの ESET を入れた mac にて開発を行っています。 この mac で、たとえば rails などの開発サーバーを立ち上げたとき、 127.0.0.1:3000 などの ipv4 経由のアクセスでは rails に問題なく疎通できますが、 localhost:3000 や [::1]:3000 でアクセスしようとすると、ネットワークが eset のファイアウォールにてブロックされてしまいます。 ブロックされた通信のログを見ていると、以下のような通信が行われようとして、しかし既存のルールで許可されずブロックされているようだ、と思っています。 日時 イベント ソース ターゲット プロトコル ユーザー 2020/05/18 14:12:03 使用できるルールが見つかりません [::]:50129 [::1c1e:c3d1:0:0]:3000 TCP root これは、ブラウザで実行しようが、 curl で実行しようが、このような通信が発生し、ブロックされ、疎通ができないような事象が発生しています。 質問 この、 ipv6 としての通信で発生している、 [::1c1e:c3d1:0:0] へ向けての接続は一体何ですか? macOS が裏で何かやって、これが発生しているのでしょうか? それとも eset 自身が何かをやっているのでしょうか? そもそも、このターゲットのアドレスは一体、何者でしょうか? 追記 Web…(Continue Reading)

HTTPからHTTPSへの通信はセキュアですか?

投稿者: Anonymous ローカルに立てた管理ページ(http://localhost:3000)からAPIサーバー(https://api.myapp.com/admin/*)へ通信し、コンテンツを編集する…という設計を考えています。 通信する際にヘッダーへ管理者用パスワードを含めるのですが、この手法はセキュアなのでしょうか。 ちなみにAPIサーバーは管理者用エンドポイントの他に公開用エンドポイントも存在します。 解決 通信のエンドポイントがJavaScriptかローカルHTTPサーバーか読み取れなかったので両方について書きます。 まずブラウザ上のJavaScriptからAPIサーバーと通信しているのであればページのオリジンに関わらずすべての通信がユーザーに筒抜けです。この場合は絶対に管理者パスワードなどを含めるべきではありません。 またローカルで動作するHTTPサーバーからAPIサーバーと通信する場合は一般のアプリケーションと同様に中間者攻撃の危険があります。またファイルシステムやメモリ上に平文でパスワードを保存した場合、比較的容易に抜き出すことができます。 程度の差はあれどちらもそれほど安全ではありません。管理権限を持たないユーザーにも配布するのであれば、埋め込みキーではなくきちんとサーバー側でユーザー認証を行うべきです。 回答者: Anonymous

PGPの鍵について

投稿者: Anonymous PGP(GnuPG)の使い方を勉強していたらいくつか疑問ができたので質問いたします。 PGPでは主鍵の他に、副鍵を複数作れると思います。 まず、(1)主鍵と副鍵の関係はどのようなものですか。 副鍵は主鍵に必ず署名されているのかなと思ったのですが、検索しても特にそのような記述は見当たりませんでした。 また、副鍵にはそれぞれに利用法(Signing、Certification(これは主鍵のみ?)、Encryption、Authentication)を設定できると思います。 Signingは署名、Encryptionは暗号化だと思いますが、 (2)Certification、Authenticationは具体的には何をするための鍵になるのでしょうか。 また、(3)これらの利用法ごとに鍵を分けるメリットはあるのでしょうか。S、E、Aは一つの副鍵で賄っても問題ありませんか。 最後に、鍵サーバに公開鍵をアップロードすることに関してですが、 (4)一般に、ある主鍵とそれに紐づく副鍵の全ての公開鍵をアップロードすることになるのでしょうか。 その場合、主鍵の公開鍵をアップロードすることになると思います。僕は主鍵の秘密鍵は常用したくない(=普段使いのPCに保管したくない)と考えているのですが、他人から自分の主鍵の公開鍵で暗号化されたデータを送られた場合、主鍵の秘密鍵で復号しなくてはなりません。そこで、主鍵の公開鍵をアップロードしない、あるいは指定した副鍵を暗号化に使うように促す方法はありますでしょうか。口頭でこの副鍵を使って暗号化してくださいと伝えるしかないのでしょうか。 まだ勉強中の身ですので、何か誤解があると思います。 質問として違和感のある部分があれば、合わせてご指摘ください。 雑多な内容で恐れ入りますが、よろしくお願いします。 解決 (1)主鍵と副鍵の関係はどのようなものですか。 主鍵、副鍵ともそれ自体は単なる鍵データです。主鍵となる鍵で署名された鍵をひとまとめとして関連づけることで主鍵と副鍵という関係が生まれます。 (2)Certification、Authenticationは具体的には何をするための鍵になるのでしょうか。 Certificationは鍵に署名するための鍵(=主鍵)です。たぶん主鍵以外にはつけられないと思います。 Authenticationは認証用の鍵で、認証というのは例えばSSHなんかで使う時が該当します。 (3)これらの利用法ごとに鍵を分けるメリットはあるのでしょうか。S、E、Aは一つの副鍵で賄っても問題ありませんか。 一部の秘密鍵だけ分離して運用できる 秘密鍵が漏洩した時の影響範囲を限定する 必要に応じて鍵の強度を変更できる 一つの鍵ペアで署名と暗号化が両方出来るとは限らない、というアルゴリズム上の制限もあります。 (4)一般に、ある主鍵とそれに紐づく副鍵の全ての公開鍵をアップロードすることになるのでしょうか。 その場合、主鍵の公開鍵をアップロードすることになると思います。僕は主鍵の秘密鍵は常用したくない(=普段使いのPCに保管したくない)と考えているのですが、他人から自分の主鍵の公開鍵で暗号化されたデータを送られた場合、主鍵の秘密鍵で復号しなくてはなりません。 主鍵には暗号化のcapabilityが付いてないので暗号化には使えません。 回答者: Anonymous

GitHubから通知された “Security Alert” の対処方法を教えてください

投稿者: Anonymous 以下の質問についてご存知の方がいらっしゃいましたらご教示を願います。 【質問の主旨】 GitHubにプッシュしているディレクトリの一部のファイルについて”serialize-javascript”というお知らせが来ました。どのように対処すれば良いでしょうか? 【質問の補足】 1. お知らせに基づいて内容を調べていくと、一部のディレクトリ内で使われている以下のコードが お知らせの原因になっていることがわかりました。 serialize-javascript”: { “version”: “1.7.0”, “resolved”: “https://registry.npmjs.org/serialize-javascript/-/serialize-javascript-1.7.0.tgz”, 2. ただしこのコードは本番環境で動いているコードではありません。自分の学習用に書いてクライアント環境(自分のパソコン)のみ動作します。 3. 学習用としてすでに用は済んでいるので、GitHubに公開しているコードとクライアント環境に保存しているコードは削除しても良いと考えています。 以上、ご確認よろしくお願い申し上げます。 解決 セキュリティ上の心配が無いようにするのであれば、アラートで説明されているように依存しているパッケージの更新をしたり変更をしたりする必要があります。ただ、既に使わなくなっているソースコードで今後も使う予定が無いのであれば、以下のような対応も考えられます。 警告を却下する。Dismiss ボタンを押し、却下理由を選ぶことができます。今回の場合は “This project is no longer maintained”(このプロジェクトはもうメンテナンスされていません)が適切そうです。 リポジトリをアーカイブし、メンテナンスされていないことを明らかにする。 リポジトリの説明文や README.md に、リポジトリがメンテナンスされていないことを明確に書き、他のユーザーが誤解して使わないようにする。 回答者: Anonymous

ターミナルの操作ログを自動で残したい

投稿者: Anonymous セキュリティと監査証跡の目的で自動的に操作ログを残すにはどうしたらよいでしょうか。 ユーザが気が付かないうちにひっそりとログを取るのが理想です。 ログに残したい情報は次の通りです。 ユーザ名 ユーザが入力したコマンドライン 端末への出力 タイムスタンプ 解決 ログインシェルをttyrecなどでラップしたシェルにすれば取れます(取っていました)。 回答者: Anonymous

ステガノグラフィについて

投稿者: Anonymous 現在、画像にデータを埋め込む”ステガノグラフィ”について調べています。 とある論文を読んでいたところ、以下のような記述を見つけました。 https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4655281&tag=1 ”マスキングを用いる手法では、LSBによる手法に比べて圧縮処理、切り取り、いくつかの画像処理に対してロバストである。(変換処理に対して強い)” “Masking is more robust than LSB insertion with respect to compression, cropping, and some image processing” この説明がよく理解できていなくて困っております。なぜ、マスキングする処理のほうがLSBに比べてロバストになるのか教えていただけますと幸いです。 解決 同引用文に続く文書が、そのまま理由説明になっていると思います(強調部は回答者による)。 Masking techniques embed information in significant areas so that the hidden message is more integral to the cover image than just hiding it in the “noise” level. This makes it…(Continue Reading)

システムアーキテクチャ的に、 Windows でウイルスは狙いやすい要因はある?

投稿者: Anonymous ウイルス、ないしマルウェアは、 ユーザーの意図しないうちに ユーザーの不利益になるような挙動をするプログラムがインストールないし実行されること だと考えられます。以下、この状態になることをマルウェア感染と言います。 ウイルス、ないしマルウェアの話題は Mac よりも Windows でよく聞く話な気がしています。上で考えたように、割と定性的にマルウェア感染を捉えるならば、それぞれの OS のシステム構成に応じて、それの起こりやすさが推測できるのではないか、と考えています。 質問: OS のシステムアーキテクチャ的に、 Mac よりも Windows の方がマルウェア感染を引き起こしやすい要因はありますか? それとも、そもそもアーキテクチャ的な要因はあまりなく、単に利用者層の違いから来るものですか? もしくは、自分の観測範囲にバイアスがかかっていて、実際には、今はもう Mac でも Windows と同じぐらいマルウェア感染はよくある事象で話題にもなっていたりしますか? プログラミングとの関連で言うと、システム的に攻撃者に利用されやすいところがどこにあるかを知ることで、システム・アプリケーションのプログラミング(ないしその設計)を行うにあたって、よりセキュアに行えるようになるのではないか、という意図があります。 解決 Mac も Windows も Unix/Linux も人が作ったものですから同じように欠陥/不具合があってしかるべきで、アーキテクチャ面では大差ないと考えるべきでしょう。実際 Mac 向けのマルウエアはいくつも報告されています。例を挙げても良いのですが広告になりそうなのでリンク略。 マルウエアを作る側からすると最小の努力で最大の成果を挙げたいわけです。 Mac ユーザと Windows ユーザでは後者のほうが多いので Windows を狙うことが多いだけです。なので相対的に Mac のマルウエアは目立たないだけで0ではない。 利用者層の違い Mac や Linux では通常の作業を管理者権限で行う人は少ないはず。一方で Windows XP の頃はめんどくさいという理由で管理者のまま通常作業をしていた人が少なからずいました。そのため感染させるのが簡単だったのですが、それは利用者層の違いというべきか意識の違いというべきか?まあ Linux ユーザでも無節操に…(Continue Reading)

Cのprintfでの$(ドルマーク)の意味

投稿者: Anonymous よくCTFなどで書式化文字列攻撃をするときに%4$xというような文字列をprintfで渡したりしますが、この書式化文字列でのドルマークの意味はどういったものでしょうか? 書式文字列攻撃について解説したこのページでも出てきています http://d.hatena.ne.jp/kusano_k/20140302/1393781714 “%n$x”という表記によって、n+1番目の引数があるべき位置の値を表示することもできる。これでスタックの先の方も覗けるし、何番目の書式指定文字か気にする必要が無くなる。 解決 POSIX仕様です。%4$xは可変引数の4番目の引数を参照することを指示します。 これでスタックの先の方も覗けるし、何番目の書式指定文字か気にする必要が無くなる。 は脆弱な環境での話で、POSIX仕様上は When numbered argument specifications are used, specifying the Nth argument requires that all the leading arguments, from the first to the (N-1)th, are specified in the format string. と指摘されています。そもそもC言語の可変引数では各引数が何バイトになるか不明なため、(N-1)thまでの引数が使われていないことにはNthの正確なアドレスは決定できません。(K&R C仕様から不明な引数はintと見なすべき…という考え方もできなくはない?) 回答者: Anonymous

angularJSのCSRF対策をしたい

投稿者: Anonymous 以下のサイトに書いてある通りにangularJSのCSRF対策をしたいと考えています。 https://docs.angularjs.org/api/ng/service/$http そこで以下のサイトを参考にしてCookieにトークンを保存しようとしました。 https://code.angularjs.org/1.3.14/docs/api/ngCookies/service/$cookies $cookies.XSRF-TOKEN = data[‘token’]; しかしこれでは Uncaught ReferenceError: Invalid left-hand side in assignment というエラーがでてできませんでした。 おそらくXSRF-TOKENが悪いのだと考えていますがこの場合どのようにして解決すればいいのでしょうか。 解決 XSRF-TOKENが引き算でないのなら $cookies[‘XSRF-TOKEN’] = data[‘token’]; と書けばいいと思いますが 回答者: Anonymous

任意のWebアプリケーションに対するセキュリティ確認について

投稿者: Anonymous 一般に提供されている任意のWebアプリケーションについて、こちらのクレデンシャル(パスワードなど)をデータベースに保存する際に暗号化しているかどうかを、開発者側からでは無くユーザー側から確認できる手段は存在しますか? 解決 ユーザといってもどういう立場なのかで違いますが 悪意あるユーザー(クラッカー)として盗みやすいサイトを探している、のであればこの場でお手伝いしないほうが良さそうです。 一般ユーザーとして「このサイトにパスワードを登録して漏れないかを心配している」のであれば 一番簡単には「パスワードを忘れた」画面で、サイト側がどういう挙動を示すかで調査することができるでしょう。 「現パスワードがメールで届く」サイトはパスワードを平文保存していると考えてよいです(非可逆変換していれば Web アプリケーション自体も元パスワードを知ることができないため)セキュリティ意識0なので近づかないほうが良さそうです。 「新しいパスワードはこれです」をメールで送ってくるサイトは(パスワードをきっちり非可逆変換して保存しているにせよ)セキュリティ意識が薄いと考えてよいです。 「このメールが届いてから*分以内に添付 URL にアクセスしたら新パスワードを設定できます」だったらそこそこ信頼してよいでしょう。当該 URL が https の場合に限ります。 サイト側がどんな言語やデータベースで Web アプリを組んでいてどうこう、を調査する行為はそのままアタック行為ですから、試すなら相手の了解を取ってから。 回答者: Anonymous

暗号化技術の重ねがけが逆効果になるケースは無いか?

投稿者: Anonymous TLSで暗号化された通信経路上を流すデータに対して、アプレイケーションのレイヤで更に暗号化を独自にかける場合、それによってかえって保護のレベルがTLS単体よりも低下する可能性はありますか? それとも、少なくともTLSによる保護のレベルまでは保証されますか? もしTLS単体よりも低下する場合、例えばどのような理由により起こり得るでしょうか? 「SSL/TLSだけだとよく脆弱性問題も起きてて心配だから、自分たちでも暗号化してセキュリティを高めよう」という話が身近にあったのですが、セキュリティ素人のアレンジが本当に有効なのかどうか気になっています。 車輪の再発明程度の問題で済むならまだしも、逆効果になってしまっては大変なので・・・ 解決 たとえば暗号に対する中間一致攻撃と言うのがあります。 平文→(1段目の暗号化)→1段目の暗号文→(2段目の暗号化)→暗号文、暗号文→(2段目の暗号化の復号)→1段目の暗号分→(1段目の暗号化の復号)→平文、という処理をしてるとして、暗号と復号のプロセスから 平文→(1段目の暗号化)→1段目の暗号文 暗号文→(2段目の暗号化の復号)→1段目の暗号文 を取り出します。これを全てのパターンの鍵で試行して、「1段目の暗号文」が一致すればその鍵が正解です。素直に全件探索すると「1段目の試行×2段目の試行」の回数がいるところ、「1段目+2段目」の回数で済むことになります。 ともに128bit鍵だとすると、256bit分の強度になるかと思いきや129bit分にしかならない、と言う話です。 また、暗号の強度はアルゴリズムそのものだけではなく運用にも関わります。 1段目の暗号の運用をきちんと考えないと、2段目が破られたら結局1段目も破られるので意味なし、ということが考えられます。(極端な例を出すと、1段目の鍵をTLSのみで暗号化して送っているとか) ということで「セキュリティを強化したつもりが全然意味なかった」ということは容易に発生しうることになります。 ここからは自信が無いのですが、1段目を加えたせいで2段目(TLS)の強度が落ちるようなことがあるかというと、1段目でヘッダなどとして構造化データを付加するとその部分が既知となり攻撃の助けになる、と言う可能性はあるかと思います。とはいっても、普通にTLSを使っていても上位レイヤのヘッダや構造化されたデータはあるので、増えると言っても微々たる物ではないでしょうか。 なんにせよ、本当にこういうことを必要とされているのであれば、専門家に支援してもらうほうが良いです。 回答者: Anonymous

ログメッセージをSyslogサーバーに転送したい

投稿者: Anonymous ログを出力するプログラムが複数あり、ログへの出力は Syslog を使っておらず普通のテキストファイルに結果を追記しています。これらのログファイルを Syslogサーバーに転送するにはどうしたら良いでしょうか。 プログラムはそれぞれ次の言語で組まれています。 Java Perl Ruby サーバー環境は CentOS6, 7, RHEL6 が混在していて それぞれのローカルディスク上に出力しています。以下は例ですが 物理、仮想合わせて50台くらいです。 (例) CentOS6: /var/log/application.log CentOS7: /var/log/appname/system.log RHEL6: /opt/app/logs/error.log Syslogサーバーは RHEL6 で Syslog-ng が動いています。 追記 また、各ログファイルは出力するプログラムの書式で、エラー、デバッグ、ワーニングが出力されているので ローカルログ毎に 条件を指定できて Error, Warning, Debug, Info レベルで Syslog出力できるのが理想です。 解決 secでログファイルを読み込んで、正規表現などでフィルターして logger に渡す方法が考えられます。 [/etc/sec/application-log.rules] type=Single ptype=RegExp pattern=(正規表現) desc=application.log Error action=pipe ‘$0’ /bin/logger -p local1.error type=Single…(Continue Reading)