ウェブ・セキュリティ基礎試験(徳丸試験)受験のすゝめ - Qiita
合格率も高く，ITSSのスキルレベルもITパスポート同等のものであるため，比較的とっつきやすい試験だと感じております． なぜ受けるべきか 「知識をつけたいなら参考書を読むだけで十分」「資格試験は取るだけでは実務に活かせる部分が少なく意味がない」等々，色々な意見があるのは重々承知していますし，どれも間違いではないと思います． ですが，「学習を進め，知識の習得率を測るために試験合格をゴールとする」ことは大変有意義なことだと私個人は思います．その理由を以下に2点述べたいと思います． セキュリティの体系的な知識は知ろうとしないと身につかない まず大前提ですが，受け身で学習していても部分的な知識しか身につきません． 受け身でいる場合，ニュースで見るようなセキュリティ事故やSNSで閲覧する表層的な知識くらい得ることができません．情報収集がしやすい反面，体系的に学ぶことができないのが欠点です． これは，
サブドメインの異なるサービス間で cookie を共有する - Qiita
例えば上記のように、異なるサブドメインにおいてもログインセッションなどのデータを共有したい場合があります。 セキュリティの都合上オリジン(<scheme>://<hostname>:<port>)の異なる場所と JavaScript 内でデータの送受信を行う場合はオリジン間リソース共有(CORS)の仕組みを利用する必要があります。 しかし、 CORS のような仕組みを信頼されうるサブドメインの違いだけで利用するのは面倒です。 今回は Cookie の仕様を用いて、データを共有出来るようにします。 要約 ;domain=example.com オプションを付けること。 domain オプションがついていなければ、現在のオリジンでしか使えないクッキーとなります。 Cookie のドメイン指定を利用する これは先ほど例に挙げたニコニコを含め、非常に多くのサービスで既に利用されている方法です。 ク
PHPのリリース日とサポート期限 - Qiita
PHP 7.0 は2018年12月3日に公式のセキュリティサポートが終了し、その前の2018年9月13日に 7.0 系最終リリースとなるはずだった 7.0.32 が公開された。しかし、セキュリティサポート終了後の2018年12月6日に 7.0.33 が公開された。 PHP 5.6 の公式のセキュリティサポートは当初2017年8月28日まで 6 だったが、5系最後のリリースであることを理由に 7 2016年始めに2018年末まで延期された。8 2018年12月6日にリリースされた 5.6.39 が最終リリースになるはずだったが、セキュリティサポート終了後の2019年1月10日に昔のよしみ (for old time's sake)で 5.6.40 がリリースされた。 9 PHP 5.5 は2016年7月10日に公式のセキュリティサポートが終了し、その前の2016年6月23日に 5.5 系最終
Let's Encrypt で手軽に HTTPS サーバを設定する - Qiita
[追記] この記事にはかなり古い情報が掲載されています。 Certbot を使うことで更に手軽に設定することが出来ますので、お試しください。 https://certbot.eff.org/ 良い時代になりましたね。 ※コメントでのご指摘ありがとうございました。 昨日、 Let's Encrypt が Public Beta になり、申請不要で誰でも利用できるようになりました。 Entering Public Beta Let's Encrypt とは Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. Let’s Encrypt is a service provided by the Internet Security Researc
アカウント削除機能に意味はない - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Webサービスでアカウント削除機能を要求するユーザの話はよく聞くわけですが、これには残念ながら全く意味が無いと、1Webエンジニアであるぼくは思っているのですが、その理由をだらだらと書いてみようと思います。非エンジニアでも分かるように書いたつもりですが、作者が特にそういう能力に秀でているわけでもないので難しいかもしれません。 技術的な問題 現代の多くのWebサービスはデータの保存をRDB(SQL)に依存しています。これには色々特徴があるわけですが、実際の実装を想定して説明していきましょう。 ユーザがいます。ここではUserというTabl
とっても簡単なCSRF対策 - Qiita
【2021/10/15 追記】 この記事は更新が停止されています。現在では筆者の思想が変化している面もありますので，過去の記事として参考程度にご覧ください。 CSRFおよびその対策の仕組みに関してはこちら↓ これで完璧！今さら振り返る CSRF 対策と同一オリジンポリシーの基礎 - Qiita この記事は，PHPにおけるワンタイムトークンを用いた実装例を示すものです。執筆日が少々古いものになるのでご了承ください。 コメント欄の議論に関するまとめ 以下，XSS脆弱性が存在しない前提．この脆弱性があるとあらゆるCSRF対策がほとんど意味をなさなくなるので，まずここから潰しておくこと． セッション固定攻撃に対する対策 ログイン後にsession_regenerate_idを必ず実行する． ログアウト後にsession_destroyを必ず実行する． CSRF攻撃に対する対策 セッションIDを抜か
OAuth 2.0 全フローの図解と動画 - Qiita
RFC 6749 (The OAuth 2.0 Authorization Framework) で定義されている 4 つの認可フロー、および、リフレッシュトークンを用いてアクセストークンの再発行を受けるフローの図解及び動画です。動画は YouTube へのリンクとなっています。 English version: Diagrams And Movies Of All The OAuth 2.0 Flows 追記 (2019-07-02) 認可決定エンドポイントからクライアントに認可コードやアクセストークンを渡す方法については、別記事『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』で解説していますので、ご参照ください。 追記（2020-03-20） この記事の内容を含む、筆者本人による『OAuth & OIDC 入門編』解説動画を公開しました！ 1. 認可コードフロー RF
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
