正規表現によるバリデーションでは ^ と $ ではなく \A と \z を使おう
正規表現によるバリデーション等で、完全一致を示す目的で ^ と $ を用いる方法が一般的ですが、正しくは \A と \z を用いる必要があります。Rubyの場合 ^ と $ を使って完全一致のバリデーションを行うと脆弱性が入りやすいワナとなります。PerlやPHPの場合は、Ruby程ではありませんが不具合が生じるので \A と \z を使うようにしましょう。 はじめに 大垣さんのブログエントリ「PHPer向け、Ruby/Railsの落とし穴」には、Rubyの落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、Ruby on Rails Security Guideからの引用として紹介されています。以下の正規表現は、XSS対策として、httpスキームあるいはhttpsスキームのURLのみを許可する正規表現のつもりです。 /^https?:\/\/[^\n]+$/
そこそこセキュアなlinuxサーバーを作る - Qiita
先日「サーバーのセキュリティ設定がなにすればいいかわからない」と相談をうけまして。 自分も初心者の時どこまでやればいいかわからず手当たりしだいにやって沼に入っていたのを思い出しながら自鯖構築したときのメモを元にまとめてみました。 注意 セキュリティ対策は用途や場合などによって違います。 自分で理解したうえで自己責任でおねがいします。 対象読者 Linuxのサーバーを建て慣れていない人 Linuxはある程度さわれる人(自分でパッケージを入れたり、サービスを止めたりできる) ラインナップ ☆は導入の重要度と導入の容易さから個人的偏見からつけた値です。 4つ以上が"最低限やること"だと思ってください。 sshd
もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog
たにぐちまことさんの書かれた『よくわかるPHPの教科書（以下、「よくわかる」）』を購入してパラパラと見ていたら、セキュリティ上の問題がかなりあることに気がつきました。そこで、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）」の章・節毎に照らし合わせて、「よくわかる」の脆弱性について報告します。主に、徳丸本の4章と5章を参照します。 4.2 入力処理とセキュリティ 「よくわかる」のサンプルや解説では、入力値検証はほとんどしていません。しかし、入力値検証をしていないからといって即脆弱かというとそうではありません。徳丸本でも強調しているように、入力値検証はアプリケーション要件（仕様）に沿っていることを確認するもので、セキュリティ対策が目的ではないからです。 「よくわかる」の中で、私が見た範囲で唯一の入力値検証は、郵便番号のチェックをするものです。以下に引用します（「よくわ
[SQLインジェクション対策]Webアプリケーションとかの入門本みたいのを書く人への心からのお願い。 - ＊「ふっかつのじゅもんがちがいます。」withぬこ
SQLインジェクションについて書くときに以下のメッセージを必ず含めて欲しいです。 単にプリペアドステートメントを使え 絶対に文字列結合でSQLを構築しようとしてはいけない IPAの「安全なSQLの呼び出し方」を読むこと なんでこんなことを書くかというと、同僚が献本されてた「プロになるためのWeb技術入門」なる本のSQLインジェクションの項で、SQLインジェクションの対策として以下のように書いてあったからです*1。 a) 値をバリデーションする b) プリペアドステートメントを使う ダメです。間違っています。単に間違っているだけでなく救いがたく間違っています。正しいSQLインジェクション対策はこう書くべきです。 単にプリペアドステートメントを使え 文字列結合でSQLを構築するな イケてない本を書く人はなんで値のバリデーションをプリペアドステートメントよりも先に書くんですか？値のバリデーション
![[SQLインジェクション対策]Webアプリケーションとかの入門本みたいのを書く人への心からのお願い。 - ＊「ふっかつのじゅもんがちがいます。」withぬこ](https://cdn-ak-scissors.b.st-hatena.com/image/square/abd76f3bb0ec0750428a791cbfbf7959c317f97d/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127052840568%2F17680117127052842215%2F1555633900)
大規模 Web サービスでログインを長期間保持するには SESSION は使わず Cookie とデータベースだけで実装する | ウェブル
先日ペコリンという Web サービスを公開したのですが、これが初めての WordPress との複合会員向けサービスだったためか、ログインが途中で切れたり、記事投稿時のリダイレクトがかかるタイミングなどで SESSION が切れてしまうことがありました。 しかし Twit Delay では長期的にログインが保持されていたり、mixi とかではログイン時間を指定できたりするので、なんとかできるものだろうと考えていたら Twitter で教えてもらいましたのでまとめておきます。 SESSION だけを使ったログインの保持では長期ログインは不可 私は今までログインの保持は以下のようにしていました。 1 2 3 4 5 <?php ini_set('session.gc_maxlifetime', 60*60*24); ini_set('session.gc_divisor', 10000); s
SSL で暗号化しても Cookie で secure 属性を指定しないと盗聴される可能性があるかもしれない
堅牢なお問い合わせフォームを作ることになり、規定書に Cookie には secure 属性を指定してねとありました。secure 属性なんて初めて聞いたので、ちょっと調べてみたところ、secure 属性以外にも expires 属性とかいろいろありますけど、知ってるやと思ったらこれも危険に繋がるみたい。 secure 属性って何 これを指定すると HTTPS の通信時のみクッキーを送信します。逆に指定しなければ HTTPS の時に作った Cookie が HTTP の時に見ることができてしまい、盗聴されることに繋がりますね。 expires 属性って何 クッキーの有効期限を指定するものなんですが、指定しなければブラウザを閉じたときは Cookie は破棄になるんですが、有効期限を指定した場合に危険があるみたいです。 この属性が指定されていなければ，ブラウザを起動していないユーザーが被害に
第3回 US-ASCIIによるクロスサイトスクリプティング | gihyo.jp
今回は、US-ASCIIによるクロスサイトスクリプティング(XSS)という話題について紹介します。 前回までで説明したUTF-7によるXSSと同様に、攻撃者はUS-ASCIIという文字コードを巧みに利用することで、IEを対象にXSSを発生させることができます。US-ASCIIによるXSSは、UTF-7によるXSSと類似点も多いため、前回までの説明も併せて読んでおくとよいでしょう。 US-ASCIIによるXSSについても先に対策を書いてしまうと、UTF-7のときと同様にHTTPレスポンスヘッダにて Content-Type: text/html; charset=UTF-8 Content-Type: text/html; charset=Shift_JIS Content-Type: text/html; charset=EUC-JP のいずれかを出力するという原則を守ることで、完全に攻撃
セキュリティ過敏症 - ぼくはまちちゃん！(Hatena)
初心者はPHPで脆弱なウェブアプリをどんどん量産すべし ↑のブックマーク うん。増田くんはいつもいいこと書くね！ ブックマークの方には 危険だとか迷惑だとか踏み台だとか色々かいてあるけれど(というか踏み台ってなんだろ？) そんなに大切な個人情報をたくさん扱ってるサイトなんてどれだけあるかな。 みんなそういうサービスつくってるの？ なんかすごいね。 ぼくの使っている範囲だと、(提供側が気をつけていないと) 本当にまずいのは銀行と証券とカード会社のような、お金のからむサービスくらいだよ。 もちろん、他にメール内容だとか、購読しているフィードだとか、知られたくない個人情報なんてのは、人によってたくさんあるよね。 だけど、例えばぼくがメールサービス作りましたなんて言ったら誰か使う？ それか無名の団体だったらどうかな。それで大切なメールやりとりしちゃうの？ そう。そもそも、利用者もそれほどバカじゃな
X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記
2011-01-06: IE8ということを追記 & ちょっと間違いを修正。あけましておめでとうございます。 年明け早々ですが、Internet Explorerの話題です。IEはご存じの通り、Content-Type だけでなくコンテンツの内容なども sniff することでファイルタイプを決定しているため、画像ファイルやテキストファイルをHTMLと判定してしまい、クロスサイトスクリプティングが発生することが昔からたびたび報告されていました*1。現在は幾分マシになったとはいえ、IEのファイルタイプの判定アルゴリズムは非常に難解であり、現在でも状況によってはWebサイト運営者のまったく意図していないかたちでのXSSが発生する可能性があったりします。そういうわけで、IEがコンテンツを sniff してHTML以外のものをHTML扱いしてしまうことを防ぐために、動的にコンテンツを生成している場合に
セキュリティの落とし穴 – Quoit Blog
この記事は7年以上前の記事です。情報が古い場合がありますのでお気を付け下さい。プログラミングをする上で、セキュリティを意識することは大変重要です。 知識が足りないためにセキュリティホールを作ってしまうこともあれば、思わぬ落とし穴があることもあります。 ふと一つ見つけてしまったので参考事例を。 リクルートが運営する「じゃらんネット」を見ているときのこと。 新規会員登録をしようと思って必要事項を入力していると、「郵便番号から住所を探す」という機能がついてました。 （画像の下のほう） 最近よく見る機能です。僕もよくつけます。 何の気なしに「住所検索」ボタンを押してみると、今入力していたページを再読み込み・・・。 ・・・ん？ ちょっと待てよ、と。 今のページ、パスワード入力してたんだけどなー。。と思ったわけです。 更新したページのソースを見てみると、案の定パスワードが平文で通信されてました。 残念
パスワードつき隠しフォルダを簡単に作る方法 | ライフハッカー・ジャパン
Windows用：共有PCを使っていて他人に見られたくないファイルがある場合、どうしていますか？ 今回は「Simple Help」に載っていた、簡単なバッチスクリプトを使ったパスつき隠しフォルダの作り方を、ご紹介します。 新規フォルダを作って、適当な名前をつけます。 フォルダを開き、空白部分で右クリック。「新規作成」から「テキスト作成」を開きます。 テキストファイルを開いて、下記をコピペします。 cls @ECHO OFF title Folder Private if EXIST "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}" goto UNLOCK if NOT EXIST Private goto MDLOCKER :CONFIRM echo Are you sure you want to lock the folder
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPでセキュリティを真面目に考える
http://designaholic.cc/2011/02/post-86.html