  |
はてなキーワード: パケットとは
閲覧者に許可なく再生する動画広告が設置されているウェブサイトを確認しております。
動画広告は、パソコンの処理能力を活用し、広告収入を得るためのツールです。動画広告が設置されたウェブサイトにアクセスした場合、ウェブサイト運営者が広告収入を得るために閲覧者のパソコンの処理能力が利用されることがあります。
動画広告を自身のウェブサイトに設置することを検討しているウェブサイトの運営者や一般のインターネット利用者は、以下の点に注意してください。
・ 動画広告を設置することを検討しているウェブサイトの運営者
自身が運営するウェブサイトに設置する場合であっても、動画広告を設置していることを閲覧者に対して明示せずにアクセスさせた場合、犯罪になる可能性があります。
動画広告が設置されたウェブサイトにアクセスすることで、パソコンの処理能力が意図せずに使用され、パソコンの動作が遅くなるなどの事象が発生する可能性があります。意図しない状況で急激にＣＰＵの利用率が高くなるなどの事象が発生した場合には、ブラウザを閉じることで事象が収まるときがあります。
また、モバイル環境においては大量のパケット（ギガ）を使用する場合があります。動画広告の再生を意図していないにもかかわらず、ウェブサイトにアクセスした際に、大量のパケット（ギガ）が消費される恐れがありますので、再度当該ウェブサイトにはアクセスしないでください。
また、ウェブサイトの中には、動画広告が設置されたウェブサイトにアクセスするタイプのほかに、実行形式のアプリを閲覧者にダウンロードさせるタイプのものもあります。閲覧者が意図せずこのアプリをダウンロードしてしまっている場合もありますので、G◯◯gleアカウントごとの削除を行うようにしてください。
自己補足。
ついでに言うと、あえてルール違反する人は例えば普通郵便に現金入れる人ならバレないように便箋で包んだりするよね。
爆発物送る人だって当然バレないように送るよね。
ISPにブラウザから普通に違法サイトへコネクション張ってくれっていうのは「違法なことします」って言いながら郵便窓口に行ってるようなものでしょ。
違法なことしたかったらそれなりに自覚した上で、torだとかVPNだとか頭を使うべきで、何も考えてない大衆のもろに「違法サイトにアクセスします」って公言してるパケットを通す権利守るのはキツくない？
郵便局は宛先の住所見て外国への郵便は高い料金取るし、北朝鮮の住所書いても送ってくれないよね？
通信の秘密があっても普通郵便で現金や法的書類送るなとか、爆発物は送るなとか中身にすらルール決めてるよね？通信内容が完全に秘密だったらわかりようがないんだからナンセンスだよね？
つまり通信事業者は宛先を見てサービス変えてるし法律に応じて中身に口出しもしてるよね？
電話だって国際電話かけたら国内電話より高い料金とられるよね？それは宛先の情報取得してるからだよね？
で、ISPにとってIPはパケット送信のための必要な宛先情報だから、ISPのサーバはフィルタリングするしないに関わらず情報としては取得してるよね？
でなんで違法な宛先を断るのがダメなの？上の例で言ったら北朝鮮に手紙送れって言ってるようなものじゃない？
俺もブロッキングは反対だけど、宛先見て遮断するだけのことに通信の秘密ってあまり盾になってなくない？
郵便局の窓口ではラベルに宛先と内容物書かされて係員に見られるよね？
客「○○宅に爆発物を送りたいんですけど」 郵便局「お断りします」
客「違法サイトの80番ポートにコネクション張りたいんですけど」 ISP「お断りします」
この2つがどう違ってなんで後者だけ通信の秘密を盾にできるのかがよくわからない
例えばメールの内容の検閲等したらそれは完全に駄目だけど、違法コンテンツしかない違法サイトにコネクション張らせないのは郵便でいう「宛先ラベル」の段階で断るだけだから検閲じゃなくない？
ついでに言うと、あえてルール違反する人は例えば普通郵便に現金入れる人ならバレないように便箋で包んだりするよね。
爆発物送る人だって当然バレないように送るよね。
ISPにブラウザから普通に違法サイトへコネクション張ってくれっていうのは「違法なことします」って言いながら郵便窓口に行ってるようなものでしょ。
違法なことしたかったらそれなりに自覚した上で、torだとかVPNだとか頭を使うべきで、何も考えてない大衆のもろに「違法サイトにアクセスします」って公言してるパケットを通す権利守るのはキツくない？
http://b.hatena.ne.jp/entry/s/co3k.org/blog/why-do-you-use-jwt-for-session
と厳しい叱責を受けたため、無能の見識を書いてみた。
「聞くは一時の恥、聞かぬは一生の恥」のとおり、
せっかくの機会のため、びしばしセキュリティに関する認識の甘さを指摘してほしい所存
作ったシステムではexpは約1時間でやってしまいました(機密保持契約違反を恐れ多少ぼかしております)
確認している間に1時間はかかるからいいやと思ってしまっていた
師はきっとJWT生成直後3秒でユーザーが
と気づいて通報
そして師が2秒で
「これは、セッションハイジャックだ！」
と検知してセッション遮断、秒速で一億円の被害が出るところを阻止する前提なのではないかと推測している
これは確かにJWTだと厳しそうだ
セッションを任意に切れることに意味はないのでは、と思えてきたが、浅はかだろうか
(師はログインを即座に検知してセッションを切れるから問題ないのか)
とにかくアカウントロック機能を作れば上記の懸念全てにきれいに対応できそうに見えている
この理屈だと例えば.envに書くような他のkeyも定期的な交換が必要に見える
これはまずい、自分の今までの見識の甘さを思い知らされた
keyは初回に設定したのみで、定期的な交換を勧める文が見つからない
私の検索力不足なのかと思ったが、もしかして彼らもこの危険性に気付いていないのではないか
JWTはhash化してつないでいる前提で
解読時間は下記を参考に、計算はwindows10の電卓アプリを用いて手動で行った
https://ja.wikipedia.org/wiki/%E7%B7%8F%E5%BD%93%E3%81%9F%E3%82%8A%E6%94%BB%E6%92%83
英数字大文字小文字で約60の時は10桁で20万年と書いているが
現代の解析技術は20万倍は速度が出ると仮定して1年として計算する
日本語に直すと60京4661兆7600億年かかる計算となった
実際にはこれが6.0466176e+17倍されさらに3600倍されつまりどういうことだ
そもそも師は何年で交換したら安全と書いていないが、何年なら安全という意見だったのだろうか
私の理解ではとかくuser_idのみ必要なら意味がないと思っていたため落ち込んでいる
まず、IDとpassを内蔵するネイティブアプリに対するapiサーバでの実装経験しかないこと
JWTが切れたら都度IDとpassを投げる方向でリフレッシュトークンは実装しなかったことを告白しておく
そのためapiサーバで上記前提で用いた場合に考えたことを書く
webアプリのJWT実装経験はないので、そちらの論は差し控えさせていただく
では危険で
JWT送信→セッション(cookie形式?)送信切り替え→セッションからuser_id取得
とりあえず思いついたのは下記だった
tokenはheaderにbearerで付けユーザーID(あるいはそれに代わる特定可能な識別子)が含まれる
httpsで通信するのでパケットキャプチャによる傍受は不可能と思っていた
(httpで通信するのはJWTとかcookieとか関係なく傍受できるため考慮しない)
0に何をかけても0なので、何回送っても解読されないならJWTを何回送っても問題ない
というかJWTが抜けるなら同様にheaderに付けるcookieでも抜けると思うので
JWTだからといって危険性に差はない、という論拠により安全性は変わらないという個人的結論になった
※余談だが、たまに送る回数が少ない方が安全という
攻撃者がアプリに保存されたJWTが取得できるならIDもpassも同じ方法で抜けそうに見えた
(厳密には保存場所が違ったかもしれんが実装依存なので同一とする)
その前提のため、わざわざ
JWT送信→セッション(cookie形式?)送信→セッションからuser_id取得
で接続しても、おそらくcookie形式で送れる何かもJWTらと同じ方法で抜かれると思われる
つまりcookieだろうがJWTだろうがアプリから直接情報が抜かれる危険性には変わりがないという結論になった
つまりcookieだろうがjwtだろうがidとpasswordの組だろうが同じ危険性で抜かれる可能性があり、いずれでも同じことができるなら
JWT→user_id
でいいじゃん、わざわざcookieと同様の形式を間に挟むの無駄じゃん、となりコメントの発言に至った
ここまで書いて、常にJWTにsession_idを含めておいて送ることを意図されていた可能性にも気づいたが
セッションにするメリットとして唯一思いついているのは任意にサーバ側でセッションを切れることだが
それを指していたのであろうか
余談だが、ブコメの雰囲気に日和って「ユーザーIDのみ入れ」(そもそもJWTを自然に作れば入るのだが)
というセッションストア的にJWTに他の情報を入れると入れない時に比べて危険性があがることに同意したような記載をしてしまったが
結局JWTが奪えたら中身に関係なくbearerとしてセットして接続するだけなので
正直JWTを使った時点でついでにセッションストアのように使おうが使わまいがセキュリティ的にそこまで変わらないのでは、と思っている
強いて上げるならセッションに保存している内容が分かる可能性があり、サーバー内部の実装が推測できる危険があるくらいだろうか
でも暗号化したらよいのでは、と思った
expを適切に設定しつつ、必要ならアカウントロック機能を入れる
(アカウントロック機能はJWTに関係なく被害の増加を抑えられる可能性がある)
少なくともapiサーバ→ネイティブアプリに関して、セッションIDを含めても危険性は変わらない
正直webアプリでも大して変わらんのでは、と思っているのは内緒である
