PHPの脆弱性への攻撃名称と対策メモ - Qiita
自分用メモ。ごちゃごちゃすると忘れるので、なるべくシンプルにまとめたい。 誤り、不備などあれば、随時追加修正します（ご指摘ありがとうございます）。 クロスサイトスクリプティング（cross site scripting、XSS） 概要 訪問者に目的のサイトとは別の罠サイトを踏ませて不正な処理を実行させる行為。 原因 フォームから受け取った値を、エスケープせずに画面に出力するために発生 （偽のフォームを作成する手法も有るので、JavaScriptの対策だけでは不足） HTMLの実体参照を用い、& を & に、< を < に、> を > に、" を " に、それぞれ置換する。 PHPではhtmlspecialchars関数を用いれば、一括で対策できる （ただしENT_QUOTESを設定しないとシングルクォーテーションはエスケープされない）
攻撃者がセッション ID を入手可能な状態で CSRF 攻撃を仕掛ける可能性について検討した - co3k.org
仕事で「フレームワークで使ってる CSRF 対策用トークンがセッション ID を基にいろいろ組み合わせた文字列のハッシュなんだけれども、なんでセッション ID 直接使わないんだよう」的な話が出たので、なんでだろうなーと考えつつ理由について検討してみたので以下に一部晒してみます（社内向けに書いたものなのでいろいろ雑だったりするのはごめんね）: 推測ですが、セッション ID が GET パラメータとかに含まれたりする可能性を避けたかったんじゃないかなあとか思います（フォームは GET でも使われうることを想定している）。 GET パラメータにセッション ID のような種類の情報は含めるべきではありません。 あと、セッション ID が盗まれた場合でも CSRF 攻撃を受けないようにするという意図もありそうな気がします。攻撃者がセッション ID を知っている状況で CSRF 攻撃を選択する状況につ
CSRF対策のトークンをワンタイムにしたら意図に反して脆弱になった実装例
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2011年1月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 橋口誠さんから今話題の書籍パーフェクトPHP (PERFECT SERIES 3)を献本いただきました。ありがとうございます。このエントリでは同書のCSRF対策の問題点について報告したいと思います*1。 本書では、CSRFの対策について以下のように説明されています（同書P338）。 CSRFへの対応方法は、「ワンタイムトークンによるチェックを用いる」「投稿・編集・削除などの操作の際にはパスワード認証をさせる」などがあります。一番確実な方法は両者を併用することですが、ユーザ利便性などの理由から簡略化する場合で
さくらのVPS（CentOS 5.5）に RapidSSL をインストールするまでのメモ
さくらのVPS（CentOS 5.5）に RapidSSL をインストールするまでのメモ 2011年4月7日 2017年9月9日 Linux さくらのVPS（CentOS 5.5）に RapidSSL をインストールするまでのメモさくらのVPS（CentOS 5.5）に RapidSSL をインストールするまでのメモ への6件のコメント tagawa SSL のインストールは初めてなので、いろいろ調べながらインストールしてみる。 サーバーはさくらのVPS、 OS は CentOS 5.5。 どこの SSL を利用するか SSL 証明書は個人的に RapidSSL 一択でした。 SSL 証明書が2000円台って安過ぎ。 以下、参考に他社の値段。 ベリサイン : 85,050円（1年） セキュア・サーバID｜製品について｜日本ベリサイン ジオトラスト : 36,540円（1年） SSL電子証明
S/MIME で メールを暗号化 する
INSANEWORKS,LLC What You Need Is What You Get!! Hostname: 133.242.243.6 IP Addr: 133.242.243.6 天気が良くないので走りにいけず、、グダグダの代表kotaです。 このお仕事をしているとよくパス付きZIPとかで機密情報をやりとりする事もあるのですが、 これには懐疑的です。というのも、、 ZIP添付メールとパスワードを単に二通に分けて出しただけ→意味ないです、、 「パスワードは私の名刺の電話番号です」→えーっと、、文末の署名に書いてる番号と同じですけど、、 とかでアレな事も少くないです。 そもそもZIPは標準だと脆弱な暗号化しかしていませんのでいかんせん注意が必要です。 ※参考リンク：Windowsで扱うZipファイルの安全性 ではどうするか？となると暗号化はS/MIMEをオススメします。 大手だと電子
PHP: セッションにセキュリティ対策する
コメントの書き方がよくわからなかったのでここで。 /* * セッションを完全に削除 */ function strict_session_destroy(){ // セッション変数を全て解除する $_SESSION = array(); // セッションを切断するにはセッションクッキーも削除する。 // Note: セッション情報だけでなくセッションを破壊する。 if (isset($_COOKIE[session_name()])) { setcookie(session_name(), '', time()-42000, '/'); } // HTTP <-> HTTPS 間でセッションの受渡し用Cookieも削除 if (isset($_COOKIE[STRICT_SESSION_ENCRYPT_NAME])) { setcookie(STRICT_SESSION_ENCRYPT_N
XSSはそのサイトを信頼している人が多いほど脅威になりうる - ぼくはまちちゃん！(Hatena)
はい！ こんにちは！ 今日は珍しくセキュリティについて一言です！ タイトルにある通り、 XSSはそのサイトを信頼している人が多いほど脅威になりうる ってことなんだけど…。これだけだと、あたりまえっぽいよね。 まずXSS脆弱性ってなに？ って人のために簡単に説明しちゃうと、これ サイトを作った人以外の人でも、好きなスクリプトを実行できちゃう状態 ってことなんだよね。 でもよく考えてみてほしい。 スクリプトが実行できる。へんなスクリプトが実行されちゃうかもしれないページ。 これって別に、「ふつうにスクリプトを許可されている、そこらへんのブログやホームページと同じ」じゃない？ いや、微妙に違うかな。 違う点はひとつ。 スクリプトを埋め込めるのが「サイトの管理者オンリー」なのか「誰でも」なのかの違いがあるんだよね。 … じゃあ、「名もなきサイトの管理者」と「誰でも」の違いってなんだろう？ なんだろ
［はまちちゃんのセキュリティ講座］ここがキミの脆弱なところ…！ 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.nisc.go.jp/conference/seisaku/dai20/pdf/20siryou0502.pdf
PHPでのセキュリティ対策についてのメモ - Liner Note
Blogger