タグ

+phpとセキュリティに関するmeets623のブックマーク (5)

  • "セキュアな PHP アプリケーションを作成するための 7 つの習慣" を全力でDISる - id:k-z-h

    セキュアな PHP アプリケーションを作成するための 7 つの習慣まずタイトルからして嫌なにおいがしたんだが、最初の項読んだだけで頭いたくなってきた。こんなクズみたいな記事を「すごい!さすがIBM様やでー!」とか、「感心した!みんなこれをみて学ぶべき!」とか言って有り難がってブクマってる奴らは脳が腐ってるんじゃないのか。 なにがクズかって言うと、全体的に中途半端。それぞれの留意点についてコードを見せて具体的な事例を挙げてるけど例示されてるコードの質が半端なく低いそもそも前提条件からしてずれてる結局具体的な対処法が書かれていない書かれている対処法がダメダメ対処法だけ書いてあってなぜそうするのかの理由が書いていない 特に最後のが重要で、「XXXしちゃいけません!」とか「XXXしましょう!」とだけ書いてると、理由がわからないのでその対処が正しいのかわからない。正しくなければもちろん問題だし、正し

  • PHP/脆弱性リスト/メモ - yohgaki's wiki

    なんだかやけに長い説明ばかり検索に引っかかったので書きました。 Linuxのローカル環境でDockerコンテナ内のXアプリ(GUIアプリ)を利用するには $ xhost localhost + を実行した後に $ docker run --rm --net host -e "DISPLAY" container_image_name x_app_binary_path とすれば良いです。 もっと読む SSHなどよく知られたサービスポートで何も対策せずにいると数えきらないくらいの攻撃リクエストが来ます。不必要なログを増やしてリソースを無駄にし、もし不用意なユーザーやシステムがあると攻撃に成功する場合もあります。 SshguardはC作られており、flex/bisonのパーサールールを足せば拡張できますがカスタム版をメンテナンスするのも面倒です。必要なルールを足してプルリクエストを送ってもマー

    PHP/脆弱性リスト/メモ - yohgaki's wiki
  • SQLエスケープにおける「\」の取り扱い

    補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブはてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2008年6月2日に公開されたもので、当時の徳丸の考えを示すものを、基的に内容を変更せずにそのまま転載するものです。 補足終わり 昨日のエントリ(徳丸浩の日記 - そろそろSQLエスケープに関して一言いっとくか - SQLのエスケープ再考)は思いがけず多くの方に読んでいただいた。ありがとうございます。その中で高木浩光氏からブクマコメントを頂戴した。 \がescape用文字のDBで\のescapeが必須になる理由が明確に書かれてない。\'が与えられたとき'だけescapeすると…。自作escapeは危うい。「安全な…作り方」3版で追加の「3.失敗例」ではDBで用意されたescape機能しか推奨していない このうち、まず「\」のエスケープが必

  • 67. PHPファイルの応答ヘッダーに含まれるPHPバージョンを隠蔽する

    ヘッダー情報からサーバーで使用しているPHPバージョンを特定されてしまい、そのバージョンのセキュリティーホールを狙った攻撃を受けてしまう可能性があります。今回は、ヘッダー情報からPHP・Apacheのバージョンを特定させない方法を紹介します。 対策がされていないサーバーへHTTPリクエストを送信し、実際にヘッダー情報を取得すると・・・ [root@localhost ~]$ telnet localhost 80 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. GET /test.php HTTP/1.0 HTTP/1.1 200 OK Date: Fri, 26 Jan 2007 12:00:00 GMT Server: Apache/2.0.59

    67. PHPファイルの応答ヘッダーに含まれるPHPバージョンを隠蔽する
  • 58. すごいリロード対策

    まず、日のサイトにある一般的な登録フォームの画面遷移は 入力画面→入力確認画面→完了画面 となっている場合が多いようです。ここでリロード問題となるのは完了画面でのDBへのINSERT処理やCSV書き出し処理、メール送信処理など「一度しか行わない処理」です。例えば完了画面へ遷移した際にブラウザのリロードボタンが押された場合、確認画面よりsubmitした情報が再度submitされて上記の一度しか行わない処理が二度行われてしまいます。そうならないよう、リロード対策はスクリプトで制御します。 まずは確認画面のスクリプト 確認画面でチケットを発行し、セッションに保存しておきます。同時に完了画面へチケットがPOSTされるよう、hiddenにセット。こうして完了画面へ遷移させます。それでは完了画面のスクリプトを見てみましょう。 このように、確認画面で発行されたチケットは一度使い切ってしまえば2度処理さ

    58. すごいリロード対策
    meets623
    meets623 2007/10/22
    ベタなチケット発行を作っておくのもいいかも
  • 1