GREE Tech Conference 2021 で発表された資料です。 https://techcon.gree.jp/2021/session/Session-7
![とあるCocos2dxアプリのチート編](https://cdn-ak-scissors.b.st-hatena.com/image/square/a2a2b85aacedabb63507c69dd057397c8d12d468/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fcocos2dx-141030125129-conversion-gate01-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
先日もtwitter上の犯行予告により20歳の青年が逮捕されたようですが、なりすましによる誤認逮捕ではなかったのか気になるところです。そこで、twitterが、なりすまし投稿をどの程度対策しているかを調べてみることにしました。twitterの安全性を確認することが目的というよりも、twitterが実施している対策を知ることにより、皆様のWebサイトを安全にする参考にしていただければと思います。 今回調べた「なりすまし投稿」の手法は下記の通りです。 クロスサイト・リクエスト・フォージェリ(CSRF) クロスサイトスクリプティング(XSS) HTTPヘッダーインジェクション クリックジャッキング DNSリバインディング クッキーモンスターバグ このうち、上の5つの解説は拙稿「“誤認逮捕”を防ぐWebセキュリティ強化術」、最後のクッキーモンスターバグについては、過去のエントリ「クッキーモンスター
(Last Updated On: 2018年8月18日)脆弱性やセキュリティ対策について技術的な話ばかりしていたので「それで結局PHPのセッション管理どうすれば良いの?」と思われた方も多いと思います。簡単にまとめます。漏れや追記した方が良い事などがあったらご指摘ください。 session_regenerate_id()の使い方(セッションID再生成) ログイン処理時・ログアウト処理には最初にsession_regenerate_idを呼ぶ。 定期的にsession_regenerate_idを呼ぶ。間隔が短いほど低リスク。 session_regenerate_idはtrueオプション(古いセッションデータ削除)を付ける。 session_regenerate_idでtrueオプションは付けない。その代わりに再生成した時点のタイムスタンプを古いセッションデータに記録し、数分後からそのセッ
Webシステムを構築する際、普通はパスワードをハッシュ化して保存するので、生パスワードを保存する人はあまりいないと思います。 (流出したら大問題ですね!) しかしWebサービスのクライアントを開発する際は、パスワードを送信する必要があるので、「パスワードを保存する」機能を実装するには何らかの形で復元できるように保存する必要があります。 もちろん、OAuthなどでトークンを保存するだけにすれば良いのですが、パスワード認証にしか対応していないサービスも多いので、避けて通れません。 AndroidでWebサービスクライアントを開発する場合を想定して、安全なパスワードの保存について考えてみましょう。 データの保存 まずは、単純なデータの保存を考えます。 Androidでアプリが終了してもデータを保存しておくには、SharedPreference、SQLite、独自ファイルなどの方式が考えられます。
ZendFramework 流れ 表示時 : token生成→hiddenセット + セッションにセット 送信時 : 送られてきたtokenをセッションにあるものと同じかでチェック token生成方法 ランダム値 + salt + 固定値 + ランダム値 md5( mt_rand(1,1000000) . $this->getSalt() . $this->getName() . mt_rand(1,1000000) ); まとめ ランダム値をセッションにいれて、送られてきたものとチェック。 Symfony 流れ 表示時 : token生成→hiddenセット 送信時 : 送られてきたtokenを、再度生成したtokenと比較して同じかチェック token生成方法 salt + 固定値 + セッションID sha1($this->secret.$intention.$this->getSe
東京ラーメンショー2011 いきてーーー!みなさんこんにちは、nakamura です。 今日はプログラマだったりサーバ管理者だったり(もしくはその両方だったり)する方にお勧めしたいサイトとツールをいくつかご紹介します。細かい脆弱性のチェック等どうしても手間が掛かるものが多いですが、今回ご紹介するツールをうまく使うとその辺りだいぶ効率よくできると思いますよ! WEB アプリケーション関連 XSS Me XSS Me :: Add-ons for Firefox XSS のテストをある程度自動化してくれる Firefox のアドオンです。残念ながら Firefox3.0.* 系の頃に開発が止まってしまっているようですが、僕の環境では install.rdf の書き換えで問題なく動作しています。(Windows7 64bit + Firefox7.0.1) SQL Inject Me SQL I
仕様 TwitterのURL自動リンクみたいな機能を実現する関数expandString(String):Stringを実装しなさい(言語自由) 入力: 文字列 出力: HTML断片文字列 以下の文字列をリンクに展開すること URL: http,httpsのURLを、そのURLへリンクする @: @(ユーザid)を、http://twitter.com/(ユーザid)へリンクする ハッシュタグ: #(ハッシュタグ名)を、http://twitter.com/#search&q=%23(ハッシュタグ名)へリンクする ただし、上記の仕様は曖昧である。詳細についてはセキュリティと利便性に配慮し決定すること。 サンプル入出力 expandString('hoge') => hoge expandString('リンク http://example.com/') => リンク <a href="ht
XSS (Cross Site Scripting) Cheat Sheet Esp: for filter evasion By RSnake Note from the author: XSS is Cross Site Scripting. If you don't know how XSS (Cross Site Scripting) works, this page probably won't help you. This page is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion. This page will also not show you how to
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
CSRF対策のtokenはセッションIDで良い セキュリティ的にワンタイムトークン>セッションIDではない。 という話が、この辺の記事に書かれています。 高木浩光@自宅の日記 - クロスサイトリクエストフォージェリ(CSRF)の正しい対策方法 高木浩光@自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由, hiddenパラメタは漏れやすいのか? 肝はこういう事のようです tokenは外部のサイトから知り難い(実質知り得ない)ものでないといけない セッションIDはcookieに格納される document.cookieは自ドメインのものと親ドメインのものしか見れない→外部サイトで動かすJavaScriptからは参照できない セッションIDは『暗号学的に安全な擬似乱数生成系で生成されているはず』(引用) 推測も事実上できない 補足すると、セッションIDを使用したCSRF対
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く