私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.121 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
jQueryが2つ以上のファイル構成なら多くの人が使ってなかっただろう
スタンスの問題では？
コード記述の便利さを取るか、コード実行の最適化を図るか
コード記述の便利さを取るか、コード実行の最適化を図るか
innerHTMLを毛嫌いするのに正当な理由がないから
jQueryで使っていても何の問題もないんだが。
明日太陽が昇らないかもって
心配しているようなもん。
jQueryで使っていても何の問題もないんだが。
明日太陽が昇らないかもって
心配しているようなもん。
うーん？ innerHTMLを根拠なく否定しているやつが
馬鹿というのが大前提なんだが、それわかってる？
そこから説明しないといかんの？
innerHTMLを否定する理由はないという
コンセンサスは得られているかな？
馬鹿というのが大前提なんだが、それわかってる？
そこから説明しないといかんの？
innerHTMLを否定する理由はないという
コンセンサスは得られているかな？
>>202
それ言うならスタイルだろ…
それ言うならスタイルだろ…
うちの上司は、すぐに、エビデンス！とかフィージビリティ！とか逆に！とか言う。
と思っていたら、気が付いたら自分も言うようになってた。
と思っていたら、気が付いたら自分も言うようになってた。
>>207
「逆に！」だけ別次元の何かを感じさせるな
「逆に！」だけ別次元の何かを感じさせるな
innerHTMLを使ったらダメという根拠は、
代入するHTMLに<script>タグが含まれていたらXSSが起きるから
逆に言えば、innerHTMLに<script>タグが含まれることがないと
保証されているなら使っていい。
ここまでは同意とれてるよね？
代入するHTMLに<script>タグが含まれていたらXSSが起きるから
逆に言えば、innerHTMLに<script>タグが含まれることがないと
保証されているなら使っていい。
ここまでは同意とれてるよね？
innerHTMLはevalと一緒。
だからevalは使ってはならない。
Googleのスタイルガイドでも
evalは絶対に使ってはならないと書いてある。
↓うっそぴょーんｗ
http://cou929.nu/data/google_javascript_style_guide/#eval
> デシリアライズ (deserialization) するときのみ使用可. (例えば RPC レスポンスを評価するときなど)
だからevalは使ってはならない。
Googleのスタイルガイドでも
evalは絶対に使ってはならないと書いてある。
↓うっそぴょーんｗ
http://cou929.nu/data/google_javascript_style_guide/#eval
> デシリアライズ (deserialization) するときのみ使用可. (例えば RPC レスポンスを評価するときなど)
ユーザーが入力した値をinnerHTMLで
代入するときは気をつけないといけないが、
プログラマが書いた文字列を代入するだけなら
安全だから問題ないんだよ。
最低限これぐらいは理解してから会話に参加してくれ。
代入するときは気をつけないといけないが、
プログラマが書いた文字列を代入するだけなら
安全だから問題ないんだよ。
最低限これぐらいは理解してから会話に参加してくれ。
そうなるとサーバサイドで文字列を無害化しなくていいって言ってるるようなもんだね
echo htmlspecialchars($s, ENT_QUOTES, 'utf-8');はしなくていい
ehoc $s;でいいみたいなことをいってるんだね
echo htmlspecialchars($s, ENT_QUOTES, 'utf-8');はしなくていい
ehoc $s;でいいみたいなことをいってるんだね
>>211
他にも問題があるけどいくらいっても理解されないようだからもういい
他にも問題があるけどいくらいっても理解されないようだからもういい
>>214
人為ミスを起こすという話をすると、
createElement('script')って書いたら、
script実行できちゃうから、
createElementも使ったらダメってことになるけどいいの？
人為ミスを起こすという話をすると、
createElement('script')って書いたら、
script実行できちゃうから、
createElementも使ったらダメってことになるけどいいの？
>>101を全く理解してないからXSSだけとか適当な事をいうんだろう
>>215
おいおい、話が全く違うだろう。
その例で言うのなら
echo 'aaa' は危険だから
echo htmlspecialchars('aaa', ENT_QUOTES, 'utf-8'); って書けって言っているようなもんだよ。
違いわかる？ ユーザーの入力値がはいった変数じゃないんだ。
プログラマが入れた固定の文字列。
だから安全なんだよ。
おいおい、話が全く違うだろう。
その例で言うのなら
echo 'aaa' は危険だから
echo htmlspecialchars('aaa', ENT_QUOTES, 'utf-8'); って書けって言っているようなもんだよ。
違いわかる？ ユーザーの入力値がはいった変数じゃないんだ。
プログラマが入れた固定の文字列。
だから安全なんだよ。
>>216
その問題はすべて反論しただろｗ
その問題はすべて反論しただろｗ
echo はミスをするとXSSを起こす。
だからechoを使うな！
↑
え？ｗ
だからechoを使うな！
↑
え？ｗ
innerHTML はミスをするとXSSを起こす。
だから innerHTML を使うな！
↑
え？ｗ
だから innerHTML を使うな！
↑
え？ｗ
script 要素に appendChild() とかやったらどうなる？
いつからバグをヒューマンエラーっていうようになったの？
バグをしたら脆弱性が起きるような命令は使ったらダメというのなら
プログラム書けないだろ。
ファイルを削除するdeleteは、バグがあったら
全ファイル消えるから使っちゃダメとか？ｗ
バグをしたら脆弱性が起きるような命令は使ったらダメというのなら
プログラム書けないだろ。
ファイルを削除するdeleteは、バグがあったら
全ファイル消えるから使っちゃダメとか？ｗ
>>225
> script 要素に appendChild() とかやったらどうなる？
そりゃ、そういうコードを書く奴が悪いというのは誰もが認めると思うが
ヒューマンエラーで「間違ってappendChild しちゃいました」なんて事が起こりうると思っているのか？
> script 要素に appendChild() とかやったらどうなる？
そりゃ、そういうコードを書く奴が悪いというのは誰もが認めると思うが
ヒューマンエラーで「間違ってappendChild しちゃいました」なんて事が起こりうると思っているのか？
>>228
いや、単純にscript要素に子要素ノードとか作れてしまうのか
と思って聞いてみたのだが
> 「間違ってappendChild しちゃいました」
例えば script 要素に id が振られていて、
間違ってその id で getElementById で要素を取得して
appendChild するようなことはあり得るかもしれない
いや、単純にscript要素に子要素ノードとか作れてしまうのか
と思って聞いてみたのだが
> 「間違ってappendChild しちゃいました」
例えば script 要素に id が振られていて、
間違ってその id で getElementById で要素を取得して
appendChild するようなことはあり得るかもしれない
>>219
え？固定された文字列でもサニタイズしないとかありえませんよ？
え？固定された文字列でもサニタイズしないとかありえませんよ？
>>230
> 例えば script 要素に id が振られていて、
> 間違ってその id で getElementById で要素を取得して
> appendChild するようなことはあり得るかもしれない
それは appendChild 以前の問題だ
それを認めるなら「間違って innerHTML しちゃいました」も起こりうるのだから
期待しなかった場所に appendChild されたのならデバッグ時に気がつくはずだし、気が付くべきだ
(気が付かなかったのならデバッグが足りない)
XSSの厄介なところは事象が発生しなければ問題にはならないという事だ
ヒューマンエラーでXSSが発生しているのなら意図的にXSSを発生しようとしなければ発見できないだろう
「間違ってappendChildしちゃいました」とは根本的に違う
> 例えば script 要素に id が振られていて、
> 間違ってその id で getElementById で要素を取得して
> appendChild するようなことはあり得るかもしれない
それは appendChild 以前の問題だ
それを認めるなら「間違って innerHTML しちゃいました」も起こりうるのだから
期待しなかった場所に appendChild されたのならデバッグ時に気がつくはずだし、気が付くべきだ
(気が付かなかったのならデバッグが足りない)
XSSの厄介なところは事象が発生しなければ問題にはならないという事だ
ヒューマンエラーでXSSが発生しているのなら意図的にXSSを発生しようとしなければ発見できないだろう
「間違ってappendChildしちゃいました」とは根本的に違う
> それを認めるなら「間違って innerHTML しちゃいました」も起こりうるのだから
ちなみに「間違って innerHTML しちゃいました」の方が想定されるリスクは大きい
script要素でなくてもXSSが起こりうるからな
ちなみに「間違って innerHTML しちゃいました」の方が想定されるリスクは大きい
script要素でなくてもXSSが起こりうるからな
ヒューマンエラーはありとあらゆるセキュリティホールの可能性があるから超危険だ
人間はプログラムを書くべきではないな
人間はプログラムを書くべきではないな
だったらプログラムを書くコンピュータを作ろう
しかしそのコンピューターのプログラムは誰が書こうか
しかしそのコンピューターのプログラムは誰が書こうか
固定の文字列をechoする時にエスケープしなくていいのは
リスクが0だから。
同様に固定の文字列。innerHTML = '<span>abc</span>'とか
XSSになりようがない。つまりリスク0だから何の問題もない。
リスクが0なのに、そのリスクがどうとか言うのは
リスク管理じゃなくて、単なる過保護。
リスクが0だから。
同様に固定の文字列。innerHTML = '<span>abc</span>'とか
XSSになりようがない。つまりリスク0だから何の問題もない。
リスクが0なのに、そのリスクがどうとか言うのは
リスク管理じゃなくて、単なる過保護。
間違って innerHTML しちゃっても問題は起きない。
なぜなら、appendChildしちゃいましたと同じだから。
appendChildしても、scriptと入れない限り大丈夫なように
inenrHTMLをscriptを入れない限り大丈夫。
この説明で同じだってことがよくわかったと思うがね。
なぜなら、appendChildしちゃいましたと同じだから。
appendChildしても、scriptと入れない限り大丈夫なように
inenrHTMLをscriptを入れない限り大丈夫。
この説明で同じだってことがよくわかったと思うがね。
過保護パターンみたいな名前のアンチパターンありそうだなｗ
例えば、if (a > 0 and a !== 0) みたいに
明らかにやる必要がないのに、念のためとかいって
やる初心者がいるんだよねｗ
こういうのは、コードがどう動くか
わかってないから。
例えば、if (a > 0 and a !== 0) みたいに
明らかにやる必要がないのに、念のためとかいって
やる初心者がいるんだよねｗ
こういうのは、コードがどう動くか
わかってないから。
>>238
appendChild と innerHTML が同じ？
appendChild と innerHTML が同じ？
チェックミスが起きるからヒューマンエラーなんだがな
appendChild と innerHTML を同一視するとか、リスクの規模を測る目を持たない人がいう事は違うな
appendChild と innerHTML を同一視するとか、リスクの規模を測る目を持たない人がいう事は違うな
>>240
はい。同じです。
固定値をinnerHTMLに入れている限りXSSは起きません。
逆に、appendChildの値をユーザーーが入力可能だとXSS起きる可能性があります。
echoも同じです。固定値ならばXSSは起きません。
違い、分かりますか？ 変数の内容がユーザーが入れられるかどうかです。
エンドユーザーが入れられるなら、XSSは起きる可能性がありますが、
固定値を入れている限りXSSは起きません。
絶対に起きません。
はい。同じです。
固定値をinnerHTMLに入れている限りXSSは起きません。
逆に、appendChildの値をユーザーーが入力可能だとXSS起きる可能性があります。
echoも同じです。固定値ならばXSSは起きません。
違い、分かりますか？ 変数の内容がユーザーが入れられるかどうかです。
エンドユーザーが入れられるなら、XSSは起きる可能性がありますが、
固定値を入れている限りXSSは起きません。
絶対に起きません。
まさにこれなんだよね。
echoをミスするとXSS起きるから、
echoを使うなっていう馬鹿はいない。
221 名前：Name_Not_Found[sage] 投稿日：2014/11/10(月) 21:57:31.58 ID:???
echo はミスをするとXSSを起こす。
だからechoを使うな！
↑
え？ｗ
222 名前：Name_Not_Found[sage] 投稿日：2014/11/10(月) 21:58:21.95 ID:???
innerHTML はミスをするとXSSを起こす。
だから innerHTML を使うな！
↑
え？ｗ
echoをミスするとXSS起きるから、
echoを使うなっていう馬鹿はいない。
221 名前：Name_Not_Found[sage] 投稿日：2014/11/10(月) 21:57:31.58 ID:???
echo はミスをするとXSSを起こす。
だからechoを使うな！
↑
え？ｗ
222 名前：Name_Not_Found[sage] 投稿日：2014/11/10(月) 21:58:21.95 ID:???
innerHTML はミスをするとXSSを起こす。
だから innerHTML を使うな！
↑
え？ｗ
>>243
バグがあったら脆弱性になるだよ。
あっ！ innerHTML使って、しかも間違って
代入するテキストにscriptタグを書いてしまった！
どんだけありえない話だよｗｗｗｗ
innerHTML使うだけじゃ何の問題も起きないからね。
innerHTMLを使ってなおかつ、ありえない条件を満たさない限りXSSは起きない。
バグがあったら脆弱性になるだよ。
あっ！ innerHTML使って、しかも間違って
代入するテキストにscriptタグを書いてしまった！
どんだけありえない話だよｗｗｗｗ
innerHTML使うだけじゃ何の問題も起きないからね。
innerHTMLを使ってなおかつ、ありえない条件を満たさない限りXSSは起きない。
プロなら過保護はやめろよｗ
いつまでも補助輪付けて
競輪に出場してるんじゃねーよｗ
いつまでも補助輪付けて
競輪に出場してるんじゃねーよｗ
>>236
お前サーバサイドやったことないだろ
お前サーバサイドやったことないだろ
こういう喩え話思いついたわｗ
あるプログラマが、echo '<p>ほげほげ</p>'というコードを書いていました。
もう一人の知障プログラマがエスケープしろ！固定値でもエスケープしろ！っと喚いて
すべてのプログラムをこう書き換えました。
echo htmlspecialchars('<p>ほげほげ</p>', ENT_QUOTES, 'utf-8');
大損害を与えたため知障プログラマは会社を首になりましたｗｗｗ
あるプログラマが、echo '<p>ほげほげ</p>'というコードを書いていました。
もう一人の知障プログラマがエスケープしろ！固定値でもエスケープしろ！っと喚いて
すべてのプログラムをこう書き換えました。
echo htmlspecialchars('<p>ほげほげ</p>', ENT_QUOTES, 'utf-8');
大損害を与えたため知障プログラマは会社を首になりましたｗｗｗ
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript スレッド一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.121 + (1001) - [100%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.141 + (881) - [97%] - 2021/4/19 9:00
- + JavaScript の質問用スレッド vol.129 + (926) - [97%] - 2017/7/27 13:45
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.120 + (1002) - [97%] - 2014/11/8 1:15
- + JavaScript の質問用スレッド vol.122 + (1004) - [97%] - 2015/2/14 4:45
- + JavaScript の質問用スレッド vol.122 + (116) - [97%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.129 + (981) - [97%] - 2016/5/5 8:16
- + JavaScript の質問用スレッド vol.128 + (1001) - [97%] - 2016/2/26 6:45
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.123 + (966) - [97%] - 2020/10/20 2:30
- + JavaScript の質問用スレッド vol.127 + (1001) - [97%] - 2016/2/4 0:15
- + JavaScript の質問用スレッド vol.127 + (160) - [97%] - 2021/7/16 9:30
- + JavaScript の質問用スレッド vol.126 + (952) - [97%] - 2015/11/18 13:15
- + JavaScript の質問用スレッド vol.126 + (348) - [97%] - 2023/1/12 17:00
- + JavaScript の質問用スレッド vol.125 + (1001) - [97%] - 2015/10/7 17:45
- + JavaScript の質問用スレッド vol.123 + (1002) - [97%] - 2015/4/27 23:30
トップメニューへ / →のくす牧場書庫について