質問の要件を満たすために、一般ユーザーからはこれらのコマンドが実行できないようにしてください。パスワードハッシュにSHA256などのメッセージダイジェストハッシュを使うことは推奨されません。パスワードハッシュ用のアルゴリズムが開発されているので、それを使いましょう。現時点でベストとされているのはArgon2です。パスワードハッシュアルゴリズムの優劣を競うコンペで2015年に最良と判断されました。scryptもしくはPBKDF2というアルゴリズムもあります。これらは出てしばらく経つので様々なシステムや言語処理系で使えるはずです。個の銅バッジ13HTTP通信における、中間の攻撃者による内容の改竄について典型的なMitMとしては、ISPが広告を挿入するという事例が複数あって問題になっています(例[1],[2])。無料をうたうISPが契約にこっそりそういう条項を入れていたりすることもあるので「攻撃」に分類されるとは限りませんが、倫理的にどうなのよ、という議論はあります。実際の攻撃に使う場合、重要な情報はhttpsで流れるのがほとんどなので、ただネット上にMitMサーバを置いて不特定多数の被害者を待ち受けるのは有効ではないでしょう。対象を絞った攻撃の1ステップとして使われる事例はあります。Updateを注入したり[3]、ルータの脆弱性を突いてDNS設定を改竄し金融機関へのアクセスを横取りしたり[4]等。DBのユーザー情報を保存しているテーブルにハッシュアルゴリズムを保存するカラムを追加します。すべてのユーザーに旧アルゴリズムを表す値を入れておくか、NULであれば旧アルゴリズムと見なす、とします。ユーザー認証時は、このカラムの値を見てアルゴリズムを選択します。パスワード変更時は新アルゴリズムを用いてハッシュ値を計算し、ハッシュ値をDBに保存するのと同時にアルゴリズム示す値も更新します。ハッシュアルゴリズムの更新を強制したい場合は、「旧アルゴリズムになっているユーザーはログイン後パスワードを強制する」という動作にすればよいでしょう。このユーザー毎にハッシュアルゴリズムを記録しておく、というのは古くから行われているオーソドックスな方法です。個の銅バッジ9SSLで保護されていないページにログインフォームが存在するサイトについてOWASPというWebアプリケーションのセキュリティに関するガイドラインを公開している団体があります。利用するようにしてください。バージョンアップにより脆弱性が解消したり、より安全になっています。以上で対応しています。セキュリティサポートが終了しています。利用する場合、以下のポイントを押さえることで安全に利用出来ます。trust)という方法を用います。入手手段(経路)としては、以下の2つが考えられます。本人から直接手渡しで入手する。信頼している人が署名した公開鍵を入手する。入手した公開鍵(a)に署名し、信頼度を設定します。trusted)」であれば、それ一つで公開鍵(b)も信頼します。trusted)」であれば、それ一つでは信頼しませんが、複数(個数は設定による)の部分的に信頼する公開鍵(a)で署名されていれば、公開鍵(b)も信頼します。個の銅バッジ9PHPのプリペアードステートメントのセキュリティについてこんにちは。$areaは引用符で囲っていないということは、数値でしょうか。その場合、例えば以下のようにします。数値の場合は、バインドする値をintなどにキャストするほうがいいです。接続先毎に公開鍵秘密鍵ペアを作る必要はありません。通常は接続元毎に公開鍵秘密鍵ペアを作ります。作った秘密鍵は接続元に置いておき、公開鍵を接続先に配布します。接続先毎に利用する秘密鍵を指定します。余談ではありますが、1つの秘密鍵を複数の接続元へ配布して再利用する、という使い方はセキュリティ上あまり褒められませんので、可能ならば避けたほうが良いでしょう。やれば働きますし、同様に外部コマンドも次のようにして実行できちゃいます。定数を触れるということは、クラスも触れるということなので、クラスに対してなんでもできると思った方がいいと思います。個の銅バッジ8Cのprintfでの$(ドルマーク)の意味POSIX仕様です。%4$xは可変引数の4番目の引数を参照することを指示します。これでスタックの先の方も覗けるし、何番目の書式指定文字か気にする必要が無くなる。個の銅バッジ8メールアドレスに記号を許すことによるリスクはありますか?私の立場は、メールアドレスを扱うシステム作る側でもありますが、組織内でどのようなメールアドレスを作っても良いか技術面から決める側でもあります。そのため、質問の趣旨と微妙にずれているかも知れませんが、どのようなメールアドレス生成を許可するのかが関心の中心となった回答になっている事にご配慮ください。考えるべきリスクは二つかと思います。自分のシステム上で不具合が起きる可能性があるかどうか。他人のシステム上で送信できない・登録できない等の不都合が起きる可能性があるかどうか。実際は1.ではなく2.についてのみ考えるべきです。どのようなメールアドレスでも、可能な限り扱えるべきであるし、拒否すべきでは無いためです。それがもっともな理由であれば、拒否することもやぶさかでは無いと思います。任意のシステムコマンドを実行できてしまうので、Webフォームなどと組み合わせて使ってしまうと、例えば単に「年齢(数字)を入力してください」としていたところに、悪意のあるユーザーは「パスワードファイルの表示」や「ファイルの削除」を試みるコマンド文字列を入力してくるケースが想定されます。これを防ぐためには、evalされる文字列はすべてエスケープしたり、潜在的に危険な機能を利用できないようにして実行するなどの対策が必要となる。個の銅バッジ7ターミナルの操作ログを自動で残したいBash限定になりますが、端末への出力以外は全て実現可能です。詳細はこちらに記載がありますので参照下さい。個の銅バッジ7webサービスの銀行口座情報はどこに保存していますかクレジットカード情報は、漏洩した場合直ちに悪用され、金銭被害に直結しますが、銀行口座情報は仮に漏洩しても金銭被害に直接つながるわけではないので、そこまで神経質にならなくてもよいように思います。心理的には被害甚大というところはあるでしょうが。普通に考えれば、暗号化してデータベースに保存というのが落とし所ですが、銀行口座情報をサイトから閲覧できなくて良いのであれば、バックオフィスのサーバーに転送してしまうという方法も考えられます。銀行名と支店名はオンライン参照を許すが、口座番号までは閲覧できないようにして、変更の場合は口座番号は入力しなおしてもらう方法が考えられます。ウェブサーバーとバックオフィスサーバーの通信時に漏洩する可能性もあるので、転送時の漏洩対策はしっかり行う必要があります。することのリスクはあるかSSHクライアントの脆弱性を突くように仕込まれたパケットを送信されて、クライアント側で任意のコードを実行されるなどで、OSごと乗っ取られる可能性があります。過去に、OpenSSHやPuTTY、TeraTerm等のメジャーなSSHクライアントで、任意のコードを実行できるような脆弱性が存在したことがあります。脆弱性が修正されたバージョンを使用していなければ、大変危険です。未知の脆弱性を利用された場合、防ぐことはほぼ不可能になります。隔離された仮想環境で行う等の方法で可能な限りリスクを低減すべきでしょう。個の銅バッジ6JavaScript&HTMLクライアント利用時の、クライアントの正当性を担保する方法についてありません。いかなる対策も、改竄をしようとするユーザが解読打破できます。質問内容からクライアント側がPCであるとします。その環境では、ユーザから隠される情報、ユーザが変更のできない情報はありません。あなたが心血を注ぐことで、ユーザーによるプログラム改竄コストを上げることはできますが、本質的な部分であなたの目的は達成不可能です。効果的な対策があるとすれは、それはサーバサイドで、クライアントの挙動をチェックをすることでしょう。個の銅バッジ6暗号化技術の重ねがけが逆効果になるケースは無いか?たとえば暗号に対する中間一致攻撃と言うのがあります。これを全てのパターンの鍵で試行して、「1段目の暗号文」が一致すればその鍵が正解です。素直に全件探索すると「1段目の試行×2段目の試行」の回数がいるところ、「1段目+2段目」の回数で済むことになります。ともに128bit鍵だとすると、256bit分の強度になるかと思いきや129bit分にしかならない、と言う話です。任意のコマンドが実行できるからです。個の銅バッジ5ターミナルの操作ログを自動で残したいログインシェルをttyrecなどでラップしたシェルにすれば取れます(取っていました)。個の銅バッジ5脆弱性対策におけるhtmlspecialchars()の使用箇所について出力時にエスケープが妥当な判断だと思います。XSS対策を行う場合、ただ単にhtmlspecialcharsだけでは防げない場合があるので注意が必要です。なりますが、XSSが発動します。複数人でそのウェブサイトを開発し運用していく上で、ソースコードを共有することは重要になります。その共有場所としてソースコードがオープンな状況になってしまう場所を選択することも多いです。GithubのPublicリポジトリが代表例ですね。WordPressなどのインストールして使うようなソフトウェアも同様です。結局のところ、「守りたいことは何か?」という点に尽きます。いうのが、あまり改竄事例が見つからない要因なのではないでしょうか。不特定多数のHTTP通信を中継・傍受するためのサーバとなると、ISPやIXクラスのものが必要になります。自前で用意するにしても他社のをクラックするにしても高コストなのは明らかです。改竄用の中継サーバを用意、あるいはサーバ乗っ取りができたところで、HTTP通信では攻撃者が欲しがるような個人情報は平文では流れてきません。フィッシングサイトを用意して、そこへ誘導するような改竄をすることも一応考えられます。ファイルを配布する際に、鍵はどうやって共有される想定なのか?公開鍵のサーバーがあるので、そこから取得できます。これはhttpsではありませんが、それ以前に単に「アップロードされた公開鍵を保存している」だけですから、その公開鍵が正規の発行元のものかどうかはわかりません。その公開鍵が信用できるかどうかは自分で判断することになります。鍵の持ち主のサイトなどに載っている鍵指紋と比較することが多いと思いますが、これは確かに改竄されている可能性があります。それでもInternetArchiveなどのサイトで最近不自然に変更されていないか確認したり、別回線からアクセスしてみたり、その人が署名した別の信頼できるコンテンツを探してみたりすることで、ある程度調査をすることは可能です。個の銅バッジ5パス名を秘匿してダウンロードさせるには可能な限り秘匿するのであればPDFをウェブから切り離してPHPからアクセスできるところにおいてPHP側でPDFを出力するという方法があります。個の銅バッジ5ブラックリストにあるURLの通信制御Siegさんも指摘されているようにXY問題に陥っているかもしれません。組み込まれているため、質問者さんがブラックリストを入手するよりも早くこれらに登録され、Webブラウザーは問題のサイトを自動的にブロックします。ネットワークを切断しようにも暗号化の問題があります。個の銅バッジ5メールアドレスに記号を許すことによるリスクはありますか?どの場面で許すかによって回答は変わってきます。記号によるタグ付けを許容するかスイッチすることができます。記号のついたメールアドレスを新規ユーザーアカウントとして認めたいとは思わないでしょう。別のユーザーに割り当てれば混乱が生じるのは明らかです。バーチャルドメインを使って一つのメールサーバーに複数のドメインを持たせ、それをMySQLで管理したとします。