アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
エンジニアの質が低すぎるのでは (スコア:3, 興味深い)
楽天日記の場合、タグのサニタイジングは要素名で判断、Javascript対策は全文検索をかけて半角文字でdocumentのような javascriptで使われる文字列が見つかると危険と判断しているようです。ユーザーも困っているようで苦情書き込みも見つけました。半年前まで興味深く見守り何度か間接的に注意を投げましたがこんな状況です。
楽天日記はログインしたままでユーザー間の日記を往復しているユーザーが多く、また奪ったアカウントは買い物や個人情報のアクセスにも使えるためセッションを奪えるとなかなか便利に使えます。
１年前はJavascriptもばんばん使える状態で、そこから継ぎ接ぎの改良を重ねてやっとこの状態。
方法論間違えた無駄な努力。小学校なら「よくがんばりましたで賞」を上げますが、この場合は無能のレッテルを貼る以外に術無し。
開発に当たるチーム/個人の基本性能が不足しているように思えます。
大手で知っているのは楽天くらいですが、他にもトップページや検索ボックスはさすがにサニタイジングしているものの hidden 要素で指定されている値を偽装してやると一発で壊れたり、問題のあるサイトは山ほどあります。コーヒーのブルックスも注文画面の一部でXSSが成立しますし、まぁ日常利用するサイトの大半、特に中堅に位置し大手のように識者からのチェックが入っていない割にユーザーを抱えているところとか恐ろしい話になっています。
某MLでもFAQ気味の質問に対してセキュリティ的にヤバい返答が入り古老があわててフォローに入るといった場面も最近になって見受けられるようになりました。
つい最近発見したXSS、、というか一切のサニタイジングを考慮しておらずGETメソッドからSQLクエリが投げれるように見えるサイトはMLの投稿歴から察するに言語歴が最低でも3年あり、現在は某ベンチャーのトップエンジニア兼社長をやっている人がコードを書いていたりします。
XSSのような危険性を持つサイトの大半はそれを指摘したり間を置いて試すと一見修正が入ったように見えるのですが突っ込んで調べるとぼろぼろ不具合が出てきます。開発者に然るべき能力が欠如しているとしか思えません。
動けばいい だけのプログラムが随分と増えてきたように思います。
また開発を指揮管理する層や発注者、リスクヘッジすべき部署にいる人や経営者の大半の認識も「動いたらそれでええんとちゃうんかい」なレベルに止まっているように思えてなりません。
Re:エンジニアの質が低すぎるのでは (スコア:3, 興味深い)
受けることになりました。
最初は、うざったいと思っていたのですが、蛇の道はヘビというか
もちはもちやというべきか、結構自信を持っていたのにボコボコに
されました。
決して安いものはないのですが、その道の第３者に診断して
もらうのはそれだけの価値があると思いますが。
Re:エンジニアの質が低すぎるのでは (スコア:2, 参考になる)
# 眠気に任せて暴走中
Re:エンジニアの質が低すぎるのでは (スコア:2, 参考になる)
関係者とお見受けします。私の知ってる人かも知れませんね。お疲れ様です。
スレ元の楽天は調べたことがありませんが、MyYahoo!のシステムも酷いもんでした。一々報告してられません。利用してるわけでもないし。
tcupも昔はとても素早く対応してくれたのですが、今や報告しても完全に無視されたままです。
掲示板の記事にタグが書き込めるとまずいということは、XSSの概念が知られるよりずっと以前から判っていたことですし、危険性は非常に高いです。
ブラウザのバグをついてPCに感染するJavaScriptで記述可能なウイルスなどもありますし、また、掲示板そのものを媒介として、掲示板を渡り歩くウイルスというのも可能です。
さらに、他サイト（１サイトとは限らない）の攻撃コードを、掲示板読者に密かに踏ませ、自分は手を汚さずに、対象サイトを停止させたり、時にはBackDoorを仕掛けさせたりすることも可能です。
office
エンジニアは一般職？ (スコア:1, 興味深い)
毎日就職ナビにセッション乗っ取りの脆弱性があります。
一応、指摘したんだけど。対策されないままです。
説明会の予約、試験の予約を取り消せたり、
個人情報を変更できちゃったり。
他、ショッピングサイトによくある脆弱性も減らないねぇ。
『https://hoghoge/product_list.cgi?cid=c001』
こんな感じのURLでGET引数を偽装する事でSQL叩けるって現状
query = "SELECT id, name FROM product WHERE category_id='" + cid + "'";
こんな事やっているだけだから、
cid=c001'; DELETE FROM product WHERE id='%
のようにcidを偽装すれば商品情報全部吹っ飛ぶぞ。
# 参照制約ついていたら、ある程度ガードされるけど。
アクセス権限もきちんとしておらず、ビューも使わない。
こんなんでいいのか日本のエンジニア！
Re:エンジニアは一般職？ (スコア:1, 興味深い)
そのときは、入ってきた値の、たとえば「'」を「\'」に変換するというような事をやっていたのですが…
設計者が「そんなことやらないでください」とか言って、削除してしまいました…
「その値はリストボックスですから、チェックする必要はないですよね？」とかって言われて。
いえ、危ないって証拠をつきつけても、「そんなことをやる人はいません」ってつっぱねられまして…。
# ついでにそこ、GETでした
必ずしも、現場のプログラマが悪い場合だけではないということを、理解しておいていただけると嬉しいのです。
# なぜ、そこまで抵抗したかというと、ほんの少しでも高速化したかったそうな…
# そのわりには、サーバ増強に頑固に反対してたな。
Re:エンジニアは一般職？ (スコア:2, おもしろおかしい)
似たような状況でいくら口で言っても理解しないので
そいつの眼前で実際にDBぶっ飛ばして証明したら怒られました。
# だったらやる前に止めろよ
Re:エンジニアは一般職？ (スコア:2)
やっぱり想像力が足りない人は設計やっちゃいかんよ。
# と妄想力最大！
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:エンジニアは一般職？ (スコア:1)
そこら辺の処理は暗黙のうちに要件と仕様に含まれていて削っちゃいけない処理だと思うのです
ちなみにPOSTでもＧＥＴでも削っちゃダメ
ユーザーが意図的に誤動作を引き起こせることには変わりないから
でも、まぁ 高速化したいけど サーバー増強に反対する気持ちはわからんでもないかな
サーバー増強はいろいろと面倒だし
Re:エンジニアは一般職？ (スコア:0)
>そこら辺の処理は暗黙のうちに要件と仕様に含まれていて
要件は提案専門のプランナーが定めてまして、仕様…というか構造設計というかは、その技術者が定めておりました。
つまるは、「そういう仕様です」
高速化 (スコア:0)
# 1%も速くなるとは思えないのでAC
Re:高速化 (スコア:0)
ただアンケートやユーザー登録など項目が多くなればそれだけチェックコストも高くなるはずです。
しかし高速化を求めるなら他によりよい方法はいくらでもあると思います。ってゆーか誰のためのサービスで何を目的とした高速化なのか、担当者の発言はそれを見失っているように思えます。
Re:高速化 (スコア:0)
>それで、何割速くなりました？
># 1%も速くなるとは思えないのでAC
手元では測定不能なほど小さな時間でした。
ぇぇ。1%どころか0.01%ですらなく、測定不能なのです（泣
Re:高速化 (スコア:0)
ボトルネックはDBとの接続でしたので、全体の実行時間は測定できる程度には長かったのですが…ということで。
Re:エンジニアは一般職？ (スコア:0)
そんな状況にしておく必然性が全く理解出来ないんだけど...。
> ビューも使わない。
ゴメンナサイ、金が無いのでMySQLです。
Re:エンジニアは一般職？ (スコア:0)
WHERE id = '$id';
とかそうですね。
昔ボルチモアテクノロジーがやっちゃっていたと思います。セキュリティ製品売ってるのにねぇ。
m(__)m (スコア:0)
Re:毎日就職ナビ (スコア:0)
試して笑ったAC
Re:エンジニアは一般職？ (スコア:0)
昔はリクエストに)を入れてるとOracleがエラー吐いてくれてました．
Re:エンジニアの質が低すぎるのでは (スコア:1)
少なくとも未だに知人のスペースで動いているGeoCitiesのゲストブックもボコボコ [geocities.co.jp]です。
Re:エンジニアの質が低すぎるのでは (スコア:1, すばらしい洞察)
SSLを正しく運用出来、またネットワーク設計に長けているような人でも、
IEは嫌いだからとか、ECMAscriptを調べるの嫌だからとか、
WebServerのアーキテクチャに興味が無かったり、等々が因して、
穴を作ってしまう例も多いですよね。
セキュリティ対策というのは危機管理なのだから、
どれだけ広範に危機の可能性を想像し対策を検討出来るかどうかが
要であるし、たとえ個人的に嫌いな技術でもそれが世に普及しているならば、
きちんと抑えておかなきゃダメなんだよと、口うるさく言ってるわけなのだが・・。
たとえ、高くとも。。。 (スコア:1, 参考になる)
私「ちょっと、見てみますね。(うちのシステムじゃないんだけど)」
私「...」
私「製造元に対応させたらどうですか。」
顧客「いろいろとあって。。。」
私「保守の範囲じゃないですか?。」
顧客「保守契約結んでいない。。。」
私「問い合わせに対してだけなら、○○だけ対策すればいいですが、
あれやら、これやらも直さないとダメですよ。」
顧客「じゃあ、○○だけしてもらえます?」
このあと、どうなったかは知らない。官庁関係なんだが。
エンジニアの質の問題よりも発注側で作る人と、チェックする 人が同一としている点がまず問題。
多くの場合、その後の保守の方が問題なのにその点を考慮して ない発注者側の問題の方がおおきい。
何事も稟議・予算獲得といった縦割り杓子定規での範囲でしか 担当者が動けず、発想や思考が硬直している。
# 多くの企業でもそうだが。
意志決定の迅速さや、裁量をある程度あたえなければ、こういった 人間が増えていくんでしょうね。
さて、問題の私の作業費用は、ベンチ等の什器をあっちやら こっちやらたどって、手元には一応来ました。
# だから、そういう事やってるから、ダメなんだって。
Re:エンジニアの質が低すぎるのでは (スコア:0)
特にセキュリティ意識が低いというか、
セキュリティという単語の意味を知らないとか（ぉ
車道のど真ん中をテクテク歩いているかのよう。
田舎の道路ならまだしも、都会の主要道のような
交通量の多いところでは、危険だっちゅうの
Re:エンジニアの質が低すぎるのでは (スコア:0)
＞開発を指揮管理する層や発注者、リスクヘッジすべき部署にいる人や経営者の大半の認識も「動いたらそれでええんとちゃうんかい」なレベルに止まっている
ってことは、上も下も全然ダメダメってことですよね。
何から手をつけりゃいいんでしょうか？
Re:エンジニアの質が低すぎるのでは (スコア:0)
＞何から手をつけりゃいいんでしょうか？
そんなあなたに
オー人事、オー人事
infoseekのiswebも。 (スコア:0)