アカウント名:
パスワード:
コンテンツは最適化と言う名の改ざんはできませんよね
※できたら大事
twitterみたいに既にクラウド側で最適化圧縮行うのもあるし
グーグル先生のサービスはどうなんだろう。
端末にあらかじめルート証明書入れればできるでしょ
そりゃ、証明書とURLのチェックでばれるでしょ
OSの提供するAPIにセキュア通信を丸投げしている場合は使われてるルート証明書のチェックとかしない。こういう加工をやる場合中間パス含めて差し替え(偽造)用の物を作ってパスも再現したりするし、結局アプリが自前で正しい証明書を別の経路で取得してそれと比較するしか無い。そしてセキュア通信APIと証明書をゴニョゴニョするなりOpenSSLなり乗っける必要もあるので結構面倒。# 当然の話なんだけど同じURLで偽装されるんでURLチェックは無意味です。
とりあえずこのタイプの事象に限って言うならMIME偽造だのポート番号変更だので対抗したほうが楽かなぁ…
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
とは言ってもセキュア通信の (スコア:0)
コンテンツは最適化と言う名の改ざんはできませんよね
※できたら大事
twitterみたいに既にクラウド側で最適化圧縮行うのもあるし
グーグル先生のサービスはどうなんだろう。
Re: (スコア:0)
端末にあらかじめルート証明書入れればできるでしょ
Re: (スコア:0)
そりゃ、証明書とURLのチェックでばれるでしょ
Re:とは言ってもセキュア通信の (スコア:0)
OSの提供するAPIにセキュア通信を丸投げしている場合は使われてるルート証明書のチェックとかしない。
こういう加工をやる場合中間パス含めて差し替え(偽造)用の物を作ってパスも再現したりするし、
結局アプリが自前で正しい証明書を別の経路で取得してそれと比較するしか無い。
そしてセキュア通信APIと証明書をゴニョゴニョするなりOpenSSLなり乗っける必要もあるので結構面倒。
# 当然の話なんだけど同じURLで偽装されるんでURLチェックは無意味です。
とりあえずこのタイプの事象に限って言うならMIME偽造だのポート番号変更だので対抗したほうが楽かなぁ…