パスワードに使用できない単語: select、insert、update、delete、drop
(id.uni-lj.si)- University of Ljubljana IDポータルのパスワードリセットは、ユーザー名と新しいパスワードの確認入力まで求めることで、アカウント復旧プロセスでの入力ミスを減らそうとする構成になっている
- ユーザー名はメールアドレスのように見える形式で、例として
js1234@student.uni-lj.siが示されている - 新しいパスワードは最低10文字以上でなければならず、名前や姓のように推測されやすい個人情報を含めることはできない
- 大文字、小文字、数字、記号
-_.+@のうち、少なくとも3つの基準を満たす必要がある select、insert、update、delete、dropのような単語もパスワードに使用できないため、単純な長さだけでなく禁止パターンまで確認する必要がある
パスワードリセットの入力フロー
- 画面は Username、New password、New password confirmation の入力欄で構成されている
- 3項目はいずれも required と表示されている
- ユーザー名はメールアドレスのように見える形式
- John Smithに相当するユーザー名の例は
js1234@student.uni-lj.si
- John Smithに相当するユーザー名の例は
- 新しいパスワードは入力ミスを減らすために2回入力する必要がある
新しいパスワードのルール
- 新しいパスワードは、ユーザーのデジタルアイデンティティを保護する手段として扱われる
- 推測されやすいパスワードは避けるべき
- 例: 名前、姓、パートナーの名前、生年月日
- パスワードは最低10文字以上でなければならない
- ユーザーの名前または姓を含めることはできない
- 次の基準のうち少なくとも3つを満たす必要がある
- 英字の大文字
- 英字の小文字
- 数字
- 記号:
-_.+@
使用できない単語
- パスワードには次の単語を使用できない
selectinsertupdatedeletedrop
1件のコメント
Hacker Newsの意見
ああ、その文字列は私が入れたものです。経営陣の要請で、いまだに理由は分かりません
このサイトはパスワードを保存しておらず、外部のアカウント管理システムを見栄えよく包んだインターフェースに近いものです
一部のレガシーアプリのログインフィールド検証がおかしく、特定の文字列を含むパスワードだと学生がログインできないという噂は聞きましたが、実例は知りません
DROP TABLE users;にすればいい。そうすれば、ベンダーのうち誰がパスワードをものすごく危険に扱っているか、すぐに見分けられますこの場合、ユーザー入力をサニタイズしていないうえ、パスワードをハッシュ化も隠蔽もしていないということなので、社会的迷惑レベルです
maxlength属性より長くなっていましたパスワードマネージャーの自動入力ではログインできるのに、手入力や貼り付けではなぜできないのか、しばらく理解できませんでした。自動入力は
maxlengthを無視していたからです"script"を含められないと言っていましたが、10代前半のころ、大きなソーシャルプラットフォーム Nettby.no をハックしたことがあります禁止語をすべて削除する方式で、その中に
scriptも含まれていましたNettbyにはHTTPSがなかったので、ARPポイズニングの中間者攻撃でみんなのパスワードを盗み、人々のアカウントでランダムな戯言を投稿して混乱を眺めていました。覗き見はしていません。14歳の私にも、どうやら最低限の倫理はあったようです
批判をかなり受けそうですが、少なくとも一部のケースでは悪くないアイデアだと思います
組織の中にはひどいコードやひどいシステムアーキテクチャを作る人が多く、それを見つけて変えさせる能力・権限・時間を持つ人は不足しています
米国では、地域の医療機関のようなひどくコーディングされたWebサイトを通じて、やむを得ず業務をしなければならないことがよくあります。こうした場合、実装がありがちなようにひどいものだと仮定し、それに合った緩和策を勧めるほうがよいかもしれません
名目上禁止されているパスワードパターンを実際には許可しているかどうかは、ユーザーが簡単にテストして監督機関に問題提起できますが、外部から正しく実装されているか確認するのは簡単ではありません
エレガントではなく悲劇的ですが、現実には物事がしばしばずさんに処理され、監督も不足しているという事実を受け入れ、最悪の結果を防ぐ緩和策を考えるほうがよいかもしれません
こうしたセキュリティ対策は、より深い問題を覆い隠してしまうことが多いです。たいていはユーザー入力を慎重に扱っていないためにこうした対策を入れるのですが、いくつかのキーワードをブロックすれば潜在的な脆弱性が「無力化」されるという前提は、多くの場合簡単に反証されます。eBayとJSFuckの事例を見れば分かります
こういう考え方が嫌いです。Webアプリケーションファイアウォール（WAF）、手抜きのペネトレーションテスト、コンプライアンスのチェックボックスが膨大な量のセキュリティ劇場を生み出し、企業に、信じられないほどひどく書かれたソフトウェアを公開インターネットに一部さらしても「安全」で「デューデリジェンスを尽くした」と信じ込ませてきたのだと確信しています
その結果、実際にはほとんど選択肢もなくデータを渡した会社から、私の最も機微な情報がまた漏えいしたという謝罪の手紙が郵便で届くことになります。きっと皆さん私のデータを心から大切に思っているので、何十年も前のJavaシリアライズライブラリの脆弱性で盗まれるままにしていたのでしょう
[1]: https://blog.checkpoint.com/research/ebay-platform-exposed-t...
どんな機関にとっても印象は悪いですが、特に能力と権限のある人々の砦であるべき大学なら、なおさら深刻です
一般的なパスワード助言としては、むしろ全員がこうしたキーワードをパスワードに入れて、バグを早く露呈させるべきです。隠れたまま攻撃者だけに使われるようにしてはいけません
ソルトを付けてからハッシュ化を何十万回も適用し、ファイルに保存されたソルト・ハッシュ値と比較すべきです
これすらできないなら、認証情報を保存するソフトウェアを書く資格はありません。本気でそう思います。ソフトウェアセキュリティは、データが有害であり、敬意を払わなければ会社を破産させかねないものだと認めるところから始まります
システムが平文パスワードをデータベーステーブルに入れてしまうのではないかと心配しなければならないなら、そのシステムには他にも恐ろしく間違い得ることが百万ほどあります。たとえばDBAがStack OverflowからSQLをコピー＆ペーストしたらどうするのでしょうか
組織に能力のないエンジニアがいるなら、独自の認証システムを実装させず、広く使われているオープンソースフレームワークや商用製品を使うほうがよいです
認証フローが、パスワードにソルトとハッシュを適用した後に元の平文パスワードを捨てること以外をしているなら、システム全体をそもそも使うべきではありません
問題ありません。代わりに
truncateを使えばいいですこの状況でいちばん笑えるのは、禁止文字列を全部チェックしているわけでもないという点です
出典：その学校の学生で、気になって自分で試しました
適切なストアドプロシージャやほかの手法でSQLインジェクションをそもそも不可能にする代わりに、いくつかのキーワードだけを制限して、ハッカーがエスケープの抜け道のような、自分たちの思いつかない方法を考え出さないことを期待しているだけ
しばらくはおそらく動くだろうけど、誰かがダメだと証明するまでの話
ユーザー入力がSQLと混ざらないようにするのは、もはやロケットサイエンスではない。2005年ではない
そもそもこれが効くなら、パスワードをハッシュ化せずに保存しているということだが、それは2005年でも愚かだった。ユーザー名やほかの入力フィールドにも同じやり方なら多少は筋が通るかもしれないが、パスワードは絶対にそんな形でデータベースに入ってはいけない
誰かがパイプ区切りのフィールドを提案したが、それも却下された。理由は「以前、一部の顧客のプロキシがパイプ文字を含むヘッダーを拒否した」みたいなものだった
ブードゥー的プログラミングは、必ずしも実地検証不足だけが原因ではない。過去に何かがうまくいかなかったことは分かっているが、証拠はなく、対処する方法もない、という場合から生まれることもある
個人的には、そのままデプロイして壊れるか見て、必要なら後から顧客と解決したい。当然ながら正当な理由で不人気なやり方なので、結局パイプ文字は使わないことになった
CGIスクリプトもたぶんtaint modeで動かしていたと思う。覚えてる？
RDBMSがハッシュ関数をサポートしている場合があるので、
UPDATE USERS SET PASSWORD = SHA2($PASSWORD)のように保存することもできる。この場合SQLインジェクションには脆弱だが、ハッシュ化されていないパスワードを保存しているわけではないハッシュ化はアプリケーション層で行うよう勧める十分な理由はあるが、正しくパラメータ化されたクエリを使うなら、データベース側でやるのもそこまでひどいわけではない
ふう、絶対に捕まえられないな。自分のパスワードは
${jndi:ldap://hunter2.com/totallylegit}だドメインに含められるのはASCII文字の
a-zと数字の0-9だけで、アスタリスクは許可されていない。許可される唯一の記号はハイフンで、先頭や末尾に置くこともできない楽観的に見れば、この要件は過度に厳格な**Webアプリケーションファイアウォール（WAF）**に由来している可能性もある
ほかのコメントはこれをアプリケーションセキュリティが悪い「証拠」と見ているが、そこまで結論づけることはできないと思う。ただし、スタックの一部がひどく実装されているという結論は出せる
古いシステムの名残のように聞こえる。一部の大学や銀行が中央認証に古いメインフレームを使っているという話を聞いたことがある
場合によっては、パスワードが平文で保存され、8文字に切り詰められたうえで、大文字だけが許可されていたと聞いた
こうしたシステムをアップグレードしない主な理由は、少なくとも私が聞いた限りでは、コストと複雑さだ。動作中のシステムを
$$$$かけてアップグレードするくらいなら、$だけかけてパスワードを制限し、基本的な「セキュリティ」を追加しよう、という感じ数年前、WordPress APIで投稿するアプリを作っていた。顧客はそれぞれさまざまなホスティング環境にWordPressをインストールしており、そこにはいくつもの「セキュリティ」機能があった
ブログに投稿すると失敗して空の内容が投稿されるというバグレポートを受け取ったのだが、こうしたセキュリティプラグインが長いブログ記事をスキャンして、
.... select fromのようなものを見つけると、そのPOSTパラメータを空文字列に置き換えていた似たような顧客からのバグレポートも見たことがあり、こちらでは私たちのサーバーから送ったリクエストのJSONフィールド内のHTMLテキストに、難読化されたJavaScriptが注入されていた。「セキュリティ」プラグインなのかマルウェアなのかは確信できなかった
selectが入っていることに気づいたが、たいていはitemselectのようなパラメータ名の一部だった。そこでスタックのどこかにWAFのようなフィルターがあるのか探した結局、商用WAFを使う前からプロキシサーバーに残っていた古い設定を見つけ、その設定が
SELECT.*UNIONを探していたあらためてURLを見ると、どれも
company=credit+unionのようなパラメータも持っていた。顔を覆ってそのコードを削除したし、ほかの場所には十分な保護策があった