【2021/10/15 追記】 この記事は更新が停止されています。現在では筆者の思想が変化している面もありますので,過去の記事として参考程度にご覧ください。 CSRFおよびその対策の仕組みに関してはこちら↓ これで完璧!今さら振り返る CSRF 対策と同一オリジンポリシーの基礎 - Qiita この記事は,PHPにおけるワンタイムトークンを用いた実装例を示すものです。執筆日が少々古いものになるのでご了承ください。 コメント欄の議論に関するまとめ 以下,XSS脆弱性が存在しない前提.この脆弱性があるとあらゆるCSRF対策がほとんど意味をなさなくなるので,まずここから潰しておくこと. セッション固定攻撃に対する対策 ログイン後にsession_regenerate_idを必ず実行する. ログアウト後にsession_destroyを必ず実行する. CSRF攻撃に対する対策 セッションIDを抜か
Symfony2を使って、AJAX通信のクライアント側とサーバ側を構築する際に、CSRF(クロスサイトリクエストフォージェリ)を防ぐためのトークンをやりとりする方法。 まずは、クライアント側画面を出力するコントローラでは、csrf_providerをつかって、トークンを生成 <?php class DefaultController extends Controller { public function clientAction(Request $request) { $token = $this->get('form.csrf_provider')->generateCsrfToken('csrf_token'); return $this->render('HogeFugaBundle:Default:client.html.twig', array( 'csrf_token' =>
言わずもがなだけど、あえて言語化しておくシリーズです。 このような手順を書くのは冗長だと思ったことはありませんか? (※mvnはMavenというJava用プロジェクト管理ツールのコマンドです。他言語の人は適当に読み替えてください) もちろん、本番作業手順書などの厳格な文書なら当然書くでしょう。でも、GitレポジトリのREADMEのような内輪のドキュメントでは・・・: どのアプリでも Maven を使っていれば mvn deploy でコンパイルするに決まっている Maven を使っていることはファイル構成から一目瞭然 うちのチームに mvn deploy を知らないプログラマーはいない(知らねえ奴はモグリだ!) だから、あえて mvn deploy 以外の方法を取る場合のみREADMEに書いた方が経済的だと思ったことはありませんか?私はあります。 でも、やっぱり、当たり前の手順であっても、
これまで「一意キー」という言葉を、 このブログでも何の気なしに使って いたので、整理の意味も含めて、 「主キー(PRIMARY KEY)」 「一意キー(UNIQUE)」 「ユニーク。インデックス(UNIQUE INDEX)」 について説明したいと思います。 まず、「主キー(PRIMARY KEY)」と 「一意キー(UNIQUE)」はテーブルに 付与する「制約(CONSTRAINT」です。 意味としては ・テーブルに格納されるレコードに 制限を付けるためのもの で、「オブジェクト」ではありません。 なので、「CREATE ~」とはせずに、 「CREATE TABLE」内に記述するか、 「ALTER TABLE ~」として、文字通り 「TABLE」オブジェクトに「付与」する ことになります。 そして、付与される「制限事項」は どちらも「テーブル内で重複しない」 ことです。なので、主キーも一意キ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く