元スレ+ JavaScript の質問用スレッド vol.121 +
JavaScript覧 / PC版 / みんなの評価 :
201 = :
jQueryが2つ以上のファイル構成なら多くの人が使ってなかっただろう
202 = :
スタンスの問題では？
コード記述の便利さを取るか、コード実行の最適化を図るか
203 = :
innerHTMLを毛嫌いするのに正当な理由がないから
jQueryで使っていても何の問題もないんだが。
明日太陽が昇らないかもって
心配しているようなもん。
204 = :
うーん？ innerHTMLを根拠なく否定しているやつが
馬鹿というのが大前提なんだが、それわかってる？
そこから説明しないといかんの？
innerHTMLを否定する理由はないという
コンセンサスは得られているかな？
205 = :
>>202
それ言うならスタイルだろ…
206 = :
>>205
スタンスで間違ってないと思うけど、衝突の原因はそこじゃないんだよね
相手を打ち負かす目的で発言している人とは論理的に議論できる気がしないよ
207 = :
うちの上司は、すぐに、エビデンス！とかフィージビリティ！とか逆に！とか言う。
と思っていたら、気が付いたら自分も言うようになってた。
208 = :
>>207
「逆に！」だけ別次元の何かを感じさせるな
209 = :
根拠はもう出てるだろ
210 = :
innerHTMLはDOMを壊す恐れがあるから使うなっ！
211 = :
innerHTMLを使ったらダメという根拠は、
代入するHTMLに<script>タグが含まれていたらXSSが起きるから
逆に言えば、innerHTMLに<script>タグが含まれることがないと
保証されているなら使っていい。
ここまでは同意とれてるよね？
212 = :
innerHTMLはevalと一緒。
だからevalは使ってはならない。
Googleのスタイルガイドでも
evalは絶対に使ってはならないと書いてある。
↓うっそぴょーんｗ
http://cou929.nu/data/google_javascript_style_guide/#eval
> デシリアライズ (deserialization) するときのみ使用可. (例えば RPC レスポンスを評価するときなど)
213 = :
ユーザーが入力した値をinnerHTMLで
代入するときは気をつけないといけないが、
プログラマが書いた文字列を代入するだけなら
安全だから問題ないんだよ。
最低限これぐらいは理解してから会話に参加してくれ。
214 = :
人的ミスがないとは言い切れない
215 = :
そうなるとサーバサイドで文字列を無害化しなくていいって言ってるるようなもんだね
echo htmlspecialchars($s, ENT_QUOTES, 'utf-8');はしなくていい
ehoc $s;でいいみたいなことをいってるんだね
216 = :
>>211
他にも問題があるけどいくらいっても理解されないようだからもういい
217 = :
>>214
人為ミスを起こすという話をすると、
createElement('script')って書いたら、
script実行できちゃうから、
createElementも使ったらダメってことになるけどいいの？
218 = :
>>101を全く理解してないからXSSだけとか適当な事をいうんだろう
219 = :
>>215
おいおい、話が全く違うだろう。
その例で言うのなら
echo 'aaa' は危険だから
echo htmlspecialchars('aaa', ENT_QUOTES, 'utf-8'); って書けって言っているようなもんだよ。
違いわかる？ ユーザーの入力値がはいった変数じゃないんだ。
プログラマが入れた固定の文字列。
だから安全なんだよ。
220 = :
>>216
その問題はすべて反論しただろｗ
223 = :
>>217
>>214はヒューマンエラーでXSS問題が起きるリスクを回避する話をしているのだと思うが
趣旨を理解しない意見で煙に巻くのがお得意のようだな
224 = :
>>223
だから、ヒューマンエラーが起きるって話をするならば、
echo は使っちゃダメってことですよね？
225 = :
script 要素に appendChild() とかやったらどうなる？
226 = :
いつからバグをヒューマンエラーっていうようになったの？
バグをしたら脆弱性が起きるような命令は使ったらダメというのなら
プログラム書けないだろ。
ファイルを削除するdeleteは、バグがあったら
全ファイル消えるから使っちゃダメとか？ｗ
227 = :
>>224
echoなど知らん
相変わらず、煙に巻くのが得意だな
228 = :
>>225
> script 要素に appendChild() とかやったらどうなる？
そりゃ、そういうコードを書く奴が悪いというのは誰もが認めると思うが
ヒューマンエラーで「間違ってappendChild しちゃいました」なんて事が起こりうると思っているのか？
229 = :
>>226
ヒューマンエラーでバグが発生するという理屈も分からないのか
原因と結果を切り分けて考えることも出来ないのか
230 = :
>>228
いや、単純にscript要素に子要素ノードとか作れてしまうのか
と思って聞いてみたのだが
> 「間違ってappendChild しちゃいました」
例えば script 要素に id が振られていて、
間違ってその id で getElementById で要素を取得して
appendChild するようなことはあり得るかもしれない
231 = :
>>219
え？固定された文字列でもサニタイズしないとかありえませんよ？
232 = :
>>230
> 例えば script 要素に id が振られていて、
> 間違ってその id で getElementById で要素を取得して
> appendChild するようなことはあり得るかもしれない
それは appendChild 以前の問題だ
それを認めるなら「間違って innerHTML しちゃいました」も起こりうるのだから
期待しなかった場所に appendChild されたのならデバッグ時に気がつくはずだし、気が付くべきだ
(気が付かなかったのならデバッグが足りない)
XSSの厄介なところは事象が発生しなければ問題にはならないという事だ
ヒューマンエラーでXSSが発生しているのなら意図的にXSSを発生しようとしなければ発見できないだろう
「間違ってappendChildしちゃいました」とは根本的に違う
233 = :
> それを認めるなら「間違って innerHTML しちゃいました」も起こりうるのだから
ちなみに「間違って innerHTML しちゃいました」の方が想定されるリスクは大きい
script要素でなくてもXSSが起こりうるからな
234 = :
ヒューマンエラーはありとあらゆるセキュリティホールの可能性があるから超危険だ
人間はプログラムを書くべきではないな
235 = :
だったらプログラムを書くコンピュータを作ろう
しかしそのコンピューターのプログラムは誰が書こうか
236 = :
>>231
あほだろ。
固定の文字列に対してエスケープする意味は無い。
237 = :
固定の文字列をechoする時にエスケープしなくていいのは
リスクが0だから。
同様に固定の文字列。innerHTML = '<span>abc</span>'とか
XSSになりようがない。つまりリスク0だから何の問題もない。
リスクが0なのに、そのリスクがどうとか言うのは
リスク管理じゃなくて、単なる過保護。
238 = :
間違って innerHTML しちゃっても問題は起きない。
なぜなら、appendChildしちゃいましたと同じだから。
appendChildしても、scriptと入れない限り大丈夫なように
inenrHTMLをscriptを入れない限り大丈夫。
この説明で同じだってことがよくわかったと思うがね。
239 = :
過保護パターンみたいな名前のアンチパターンありそうだなｗ
例えば、if (a > 0 and a !== 0) みたいに
明らかにやる必要がないのに、念のためとかいって
やる初心者がいるんだよねｗ
こういうのは、コードがどう動くか
わかってないから。
240 = :
>>238
appendChild と innerHTML が同じ？
241 = :
チェックミスが起きるからヒューマンエラーなんだがな
appendChild と innerHTML を同一視するとか、リスクの規模を測る目を持たない人がいう事は違うな
242 = :
>>240
はい。同じです。
固定値をinnerHTMLに入れている限りXSSは起きません。
逆に、appendChildの値をユーザーーが入力可能だとXSS起きる可能性があります。
echoも同じです。固定値ならばXSSは起きません。
違い、分かりますか？ 変数の内容がユーザーが入れられるかどうかです。
エンドユーザーが入れられるなら、XSSは起きる可能性がありますが、
固定値を入れている限りXSSは起きません。
絶対に起きません。
243 = :
>>241
チェックミスって何のチェックですか？
コードにバグがないかチェックしないんですか？
244 = :
まさにこれなんだよね。
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 を使うな！
↑
え？ｗ
245 = :
>>243
バグがあったら脆弱性になるだよ。
あっ！ innerHTML使って、しかも間違って
代入するテキストにscriptタグを書いてしまった！
どんだけありえない話だよｗｗｗｗ
innerHTML使うだけじゃ何の問題も起きないからね。
innerHTMLを使ってなおかつ、ありえない条件を満たさない限りXSSは起きない。
246 = :
プロなら過保護はやめろよｗ
いつまでも補助輪付けて
競輪に出場してるんじゃねーよｗ
247 = :
>>236
お前サーバサイドやったことないだろ
248 = :
>>247
お前がやったことないだろ。
はい論破ｗ
249 = :
こういう喩え話思いついたわｗ
あるプログラマが、echo '<p>ほげほげ</p>'というコードを書いていました。
もう一人の知障プログラマがエスケープしろ！固定値でもエスケープしろ！っと喚いて
すべてのプログラムをこう書き換えました。
echo htmlspecialchars('<p>ほげほげ</p>', ENT_QUOTES, 'utf-8');
大損害を与えたため知障プログラマは会社を首になりましたｗｗｗ
250 = :
ところどころ全然的を得てない例を出してる人は流れの邪魔
前へ 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
トップメニューへ / →のくす牧場書庫について