アカウント名:
パスワード:
いまだに12文字制限のあるとこ（ゆうちょとか）、さらに8文字制限のクレジットカード系とかほんと勘弁してほしい。
記号入力必須なのに、特定の記号以外は入力制限がある(いまどき、SQL文でも直書きしてるの？)とかもやめてほしい。
Webアプリケーションファイアウォールってのがあってだな、記号有りにして、例えば「t' OR 't' = 't」みたいなパスワード使われてしまうと誤検出が発生してしまう。
誤検出を防ぐには、当該ページ（例えば login.php への POST）に対してWebアプリケーションファイアウォールを無効にするしかなくなる。すると、万が一SQLインジェクションとかOSコマンドインジェクションとかの脆弱性があっても、Webアプリケーションファイアウォールが作動しなくなってしまう。
なので、
・Webアプリケーションファイアウォールによって脆弱性があった場合にも悪用を防げる（場合がある）ことのメリット・記号を入れた分、ユーザのパスワードが強固になることのメリット
のどちらかを天秤にかけることになる
パスワードに記号を禁止してもユーザは強固なパスワードを指定することは可能（その分長くすればいいだけ）だし特定のユーザのパスワードが破られてもシステム全体には影響しないし会社としてのダメージは少ないしかし、SQLインジェクションでもされたら会社は大損害でイメージもがた落ち
なので、金融系とかクレジットカード系など、安全性が重視されるシステムほど、パスワードへの記号の使用は禁止して、Webアプリケーションファイアウォールで安全性を担保している
金融系とかクレジットカード系など、安全性が重視されるシステムほど、クライアントサイドでのハッシュとか、説明が難解な方法が拒絶されて、セキュリティが低下しがち…?
> クライアントサイドでのハッシュそんなことの為にJavaScript必須にするのはやめてくれ
そういうことされるとパスワードマネージャの種類やバージョンによっては自動入力やログインが上手くいかなくなって不便なんだよね。
SQL-INJやXSSなんて当然セキュリティ会社にチェックしてもらうでしょうせいぜい禁止記号縛りならわかるけど長々と何コメントしてんだか
何言ってんだこいつ。そんな本末転倒な代物に頼らざるをえない時点でそのシステムダメだろ。だいたいSQLインジェクションっていうが、その程度だと悪意ある入力はともかく、普通の入力だって記号関係がダメになってるってことだぞ。そんなの脆弱性以前の問題だっての。もっと、こう文字コード由来のインジェクションを防ぐってFWならともかくさ。当然そんな誤検出なんてありえん。
この長文はプレースホルダやせめてエスケープ処理を知らない昔の人ですか？
「ファイヤウォールがSQLインジェクション攻撃と誤認してアクセスをブロックしてしまう」ことを問題にしているのであって、ウェブアプリがSQLインジェクション対策されてるかどうかは無関係。
別のコメントみたいに「そんなファイヤウォールに頼るな」というツッコミは正当だけど、プレースホルダとかエスケープ処理とか「SQLインジェクション対策しろ」というコメントはまったくの的外れ。
WAFって今時どこでも使ってる気がするけど、金融系でだけそんな問題が発生するの? それは金融系のセキュリティが甘いってことじゃないの?
金融系は真っ先にWAF入れた真っ先に入れたからチャチかったので先のようなことになったそれに対応するためのバッドノウハウも必要だった
東京都心の地下鉄駅が狭くてぼろいようなもん
WAF知ってるけど、だからなに？
出来の悪いWAFのために、ユーザー側を制限しますって馬鹿？
安全性が重視されるシステムほど、認証用のデータベース（およびページ）とそれ以外を切り離したほうがいいに決まっているじゃない。設計ミスを他人のせいにするのはやめましょう。
SQLインジェクションはSQL発行する段階で防止すればいい話じゃないの？結局そのファイアウォールをあてにした杜撰なプログラムになったりページによって例外的にそのファイアウォールを無効にするとかややこしい実装になったりでかえってセキュリティが低下するような気がするんだけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
文字数制限 (スコア:1)
いまだに12文字制限のあるとこ（ゆうちょとか）、さらに8文字制限のクレジットカード系とかほんと勘弁してほしい。
Re: (スコア:0)
記号入力必須なのに、特定の記号以外は入力制限がある
(いまどき、SQL文でも直書きしてるの？)とかもやめてほしい。
Webアプリケーションファイアウォールを知らないの？ (スコア:1)
Webアプリケーションファイアウォールってのがあってだな、
記号有りにして、例えば「t' OR 't' = 't」みたいなパスワード使われてしまうと誤検出が発生してしまう。
誤検出を防ぐには、当該ページ（例えば login.php への POST）に対してWebアプリケーションファイアウォールを無効にするしかなくなる。
すると、万が一SQLインジェクションとかOSコマンドインジェクションとかの脆弱性があっても、Webアプリケーションファイアウォールが作動しなくなってしまう。
なので、
・Webアプリケーションファイアウォールによって脆弱性があった場合にも悪用を防げる（場合がある）ことのメリット
・記号を入れた分、ユーザのパスワードが強固になることのメリット
のどちらかを天秤にかけることになる
パスワードに記号を禁止してもユーザは強固なパスワードを指定することは可能（その分長くすればいいだけ）だし特定のユーザのパスワードが破られてもシステム全体には影響しないし会社としてのダメージは少ない
しかし、SQLインジェクションでもされたら会社は大損害でイメージもがた落ち
なので、金融系とかクレジットカード系など、安全性が重視されるシステムほど、パスワードへの記号の使用は禁止して、Webアプリケーションファイアウォールで安全性を担保している
Re: (スコア:0)
金融系とかクレジットカード系など、安全性が重視されるシステムほど、クライアントサイドでのハッシュとか、説明が難解な方法が拒絶されて、セキュリティが低下しがち…?
Re: (スコア:0)
> クライアントサイドでのハッシュ
そんなことの為にJavaScript必須にするのはやめてくれ
Re: (スコア:0)
そういうことされるとパスワードマネージャの種類やバージョンによっては自動入力やログインが上手くいかなくなって不便なんだよね。
Re: (スコア:0)
SQL-INJやXSSなんて当然セキュリティ会社にチェックしてもらうでしょう
せいぜい禁止記号縛りならわかるけど長々と何コメントしてんだか
Re: (スコア:0)
何言ってんだこいつ。
そんな本末転倒な代物に頼らざるをえない時点でそのシステムダメだろ。
だいたいSQLインジェクションっていうが、その程度だと悪意ある入力はともかく、普通の入力だって記号関係がダメになってるってことだぞ。
そんなの脆弱性以前の問題だっての。
もっと、こう文字コード由来のインジェクションを防ぐってFWならともかくさ。
当然そんな誤検出なんてありえん。
Re: (スコア:0)
この長文はプレースホルダやせめてエスケープ処理を知らない昔の人ですか？
Re:Webアプリケーションファイアウォールを知らないの？ (スコア:1)
「ファイヤウォールがSQLインジェクション攻撃と誤認してアクセスをブロックしてしまう」ことを問題にしているのであって、ウェブアプリがSQLインジェクション対策されてるかどうかは無関係。
別のコメントみたいに「そんなファイヤウォールに頼るな」というツッコミは正当だけど、
プレースホルダとかエスケープ処理とか「SQLインジェクション対策しろ」というコメントはまったくの的外れ。
Re: (スコア:0)
WAFって今時どこでも使ってる気がするけど、金融系でだけそんな問題が発生するの? それは金融系のセキュリティが甘いってことじゃないの?
Re: (スコア:0)
金融系は真っ先にWAF入れた
真っ先に入れたからチャチかったので先のようなことになった
それに対応するためのバッドノウハウも必要だった
東京都心の地下鉄駅が狭くてぼろいようなもん
Re: (スコア:0)
WAF知ってるけど、だからなに？
出来の悪いWAFのために、ユーザー側を制限しますって馬鹿？
安全性が重視されるシステムほど、認証用のデータベース（およびページ）と
それ以外を切り離したほうがいいに決まっているじゃない。
設計ミスを他人のせいにするのはやめましょう。
Re: (スコア:0)
SQLインジェクションはSQL発行する段階で防止すればいい話じゃないの？
結局そのファイアウォールをあてにした杜撰なプログラムになったり
ページによって例外的にそのファイアウォールを無効にするとかややこしい実装になったりで
かえってセキュリティが低下するような気がするんだけど。
Re: (スコア:0)
普通にFW屋に行ってWAF買ってくればSQLインジェクションをブロックしてくれるFWが売ってる