  |
はてなキーワード: sqlインジェクションとは
SQLインジェクションで穴作りたくないとバリデーションチェックでむやみやたらに全角押し付けた結果じゃないかな。
基本設計書にセキュリティ的な観点は入っても、全体を通したUI観点なんてまずみないから、
その時点でお仕着せのようにここフリースペースなので全角オンリーねとアホの一つ覚えで決まったのでしょう。
全角⇔半角の処理を入れてUI向上を図りたい、その分、もちろん工数貰いますが、どうですか？なんて提案が
実際に作成する三次請け、四次請けの現場から出るとは思わないし、
んで、プログラマー()とか言ってる奴の仕事の大半はただただ命令通りにコードを書いてくだけなんだから一昔まえの事務仕事と一緒。
誰でも出来る簡単なお仕事。
なぁなぁ、それってどうやって実現してんだ?
SI界隈でメシ食ってるけど、見てきたコードの9割がクソコードなんだが。今日でも20年前より状況が良くなってる感じがしないぞ。
ヒープとスタックの区別も知らないスコープの意味もわかってない時間計算量も空間計算量も考慮されてなくて、
利用者が1人なら動くけど10人で利用すると挙動がおかしいとか、
データが100件ならすぐ終わるけど10000件だと24時間たっても終わらないとかメモリがあふれるとか、
月や年をまたいだはずなのに32日になってるとか13月になってるとか、月末締切のはずなのに月末の前日に締め切られるとか、
SQLインジェクションどころか認証もしてないのに他人のパスワード書き換えられるとか、
カンマやダブルクォートを入力したらCSVな出力データが壊れるとか、
マルチバイト文字列をバイト単位で分割して分割部分の文字を壊すとか、
そういうことがおきないんだよな? おまえのとこでは。
本当にどうやって実現してるんだ?
どうせSQLインジェクションとかサニタイズしてなかったとかその程度のレベルなんだろ？そんなのセキュリティ対策とは言わない。常識的なレベル。さすがにこの程度の指摘で根をあげてたら何も成長しないぞ
システム管理者から言わせてもらうと、これだけの情報ではシステム停止対応をした是非は判定できないが、
おそらくは、事前通知なしのシステム緊急停止は行きすぎた対応ではないかと思う。
それに、この派遣社員は、テスターとしては合格だが、技術者としては微妙。ビジネスマンとしてはアウトだ。
このケースは、「SQLインジェクション」といって、攻撃により情報漏えいが起きる可能性であり、
システムにセキュリティ上の致命的な欠陥が潜在的に存在すると分かっただけで、事前通知なしの緊急停止という対応は普通はしない。
逆に、具体的な攻撃が観測された場合、または通常の操作で情報漏えいが発生する欠陥が見つかった場合などは、迷いなく事前通知なしの緊急停止に踏み切るべきだ。
プライベートの趣味のサイトであれば即停止でもよいだろうが、ビジネスで使っているシステムである以上、セキュリティだけでなく、事業継続性や説明責任や止めた場合の影響も考慮すべき。
緊急度や対応方法もいろいろなバリエーションがあるし、インシデント発生対応時のマニュアルを参照しつつ、状況を照らして迅速に判断することになる。
なお、判断するのは、あくまで正社員の責任者（内容によっては経営者が）であって、派遣社員ではない。
ただ会社側の体制に問題があると思う。
派遣社員の暴走？も、会社側がこういう場合の対応について考えるきっかけを与えることになっただろうから、それはそれで意義はあったのではないかと思う。
システムのことさっぱりわからない経営者やマネジメント側の人間ができることは、
(1)派遣社員には、システム運用稼働中に本番サーバを触らせないように権限を決めておく。
(2)その代わり、システム管理者として、スキルと判断力と責任感を兼ね備えた人材(正社員)を配置しておく。
ことだろう。
プライバシーマークやISMSを取得すれば、こういうことが体系的にできる。
私がもしこのテスター(派遣社員)から運用中のシステムの脆弱性を指摘されたらどうするか考えてみた。
（そもそもこんな品質レベルのシステムは導入する時に却下するだろうが。）
(2)上司に口頭で「XXシステムで、セキュリティ上の問題発生、これより対応開始します」と報告。時刻を記録。
(3)状況を確認する。
（「SQLインジェクション」脆弱性が存在することがわかった。
アクセスログなどから攻撃や情報漏えいの痕跡はとりあえず見当たらない。
ただし、攻撃は比較的容易で、個人情報が流出する可能性があることが分かった。）
(4)対応方法を判断する。
緊急性、停止方法、影響、修正、暫定復旧のめどを見積もる。
（1時間以内に顧客通知を完了した上で、システムを停止して調査するとする。）
トラブル対応は手がいるので助っ人を頼む。顧客への連絡などは、営業担当者でも手伝ってもらえるはずだ。
システム停止後は、攻撃や情報漏えいが起きたか起きなかったかの調査が先になるだろう。
もちろん致命的なバグを仕込んだ開発者は呼びつけて調査に加わらせる。
都度、時刻を記録するのは、後で顧客に提出する報告書を書くためだ。
また、システム停止前に利用者に事前通知するかどうかは重要なポイントで、
更新処理中にシステムを停止すると、データの内容に不整合が生じる可能性もある。
事前通知なしでシステム止めた場合、責任上これが問題となってくるし、データ不整合が発生したら、その分復旧も遅れだろう。これひとつとっても、やみくもにシステム停止すればよいわけでは決してない。
備えあれば憂いなし。
HTMLはわかるけど、サーバーサイドはお遊びでphpを触ったぐらいだったので、会員制でデータをためこむサイト作りに初めて挑戦した。
今回重視したのは、「いかに個人情報をお漏らししないようにして、万が一漏らしても被害を少なくするか」ということ。
世の中、有償サービスでもパスワードを平文で保存してるサービスが意外と多いらしいので、流出した時のリスクを少しでも減らせる対策として書きます。
サーバー：ロケットネットのキャンペーンにでレンタルサーバ年１０００円ポッキリプラン クライアント側の処理：HTML+CSS+jQuery（とプラグインもろもろ） サーバ側の処理：PHP Webサーバー：Apache データベース：MySQL
俺も巻き込まれたところでは、サミータウンがメールアドレスとパスワードセットでお漏らししてお詫びに１ヶ月無料なにそれこわい。
サミータウンだけならまだいいけど、メアドとパスワードを他のサービスで共通化して使ってる情弱なので、
共通化してメアドとパスワードをどこかのサービスが一箇所でも漏らすと、ヤフオクID乗っ取り事件みたいなことになる。
http://internet.watch.impress.co.jp/cda/news/2008/09/26/20967.html
俺だってできれば人様のメールアドレスとパスワードとか預かりたくない。
万が一、肉親のメールドレスを発見してパスワードにrapemeとか入ってたら明日からどういう顔すればいいかわからない。
ググってみてもどこにも情報のってない。うーん困った。ダメもとで「個人情報ってどうやって保存したらいいんだろう。。。」
って、twitterでつぶやいたら、「住所とかは可逆暗号化でいいけど、パスワードはハッシュで不可逆化しないとだめだよ！」
「住所とかは可逆暗号化でいいけど、パスワードはハッシュで不可逆化しないとだめだよ！」
何のことかわからなったので、調べてみると、
・ハッシュ＝ハッシュ値を使った、元のデータに戻せない暗号化方式
うーん。。。よくわからん。。。
電話番号とか住所は、第三者が使用する情報なので、可逆が必要。パスワードは、認証にしか使わないので、
ハッシュ値の結果が一致すれば元のデータがわからなくてもOK、という方式なのでこういった暗号の使い分けをする。
●可逆暗号のイメージ（もとにもどせる） 暗号化キーは開発者が指定する。 090-xxxx-xxxx →（暗号化）→ !'&%($% →（復号化）→ 090-xxxx-xxxx ●ハッシュのイメージ（もとにもどせない） 登録password（DBに保存）→（ハッシュ値抽出）→!"$#'$#=" ログインpassword →（ハッシュ値抽出）→!"$#'$#=" ※二つのハッシュ値が合っていれば、パスワード一致として認証する。
今回はMySQLの関数で実現した。encode関数で暗号化して、decode関数でもとに戻す。
例えばtel_noという項目だけあるテーブルがあるとすると、
//データベースに保存する時 insert into テーブル名 (tel_no) values (encode(tel_no,'暗号化キー')); //データベースから取得する時 select decode(tel_no,'暗号化キー') from テーブル名;
これで、データベース格納時は暗号化（バイナリ化）されて、データベースから取り出してHTML表示する時に復号化はされる。
＜ユーザ登録時＞
$password=（フォームから取得） $hash=hash('sha512',$password) //ユーザ登録時は、ここで生成した$hashをデータベースにぶっこむ。
ユーザ認証時は、入力されたパスワードと、データベースのパスワードが一致するかチェック。
//フォームから入力されたパスワード $input_password=（フォームから取得） $input_hash=hash('sha512',$input_password); //MySQLに保存されたパスワードを取得（略） $db_hash==（データベースから取得） //判定 if($input_hash==$db_hash) echo 'ログインしますよ！'; //ここにログイン処理を書く else die('メアドとパスワードがあってないよ！');
これでもしSQLインジェクションとかでデータが流出しても、ハッシュ暗号のパスワードに関してはまず解析されないはず。。。
可逆暗号のデータもphp側の暗号化キーが盗まれない限りバレない。。。はず。。。
何でもかんでも暗号化するとコードが煩雑になるし、パフォーマンスにも影響でそうなので、
住所データの都道府県とか、漏れても良いような情報は暗号化しませんでした！！
個人情報保護法 2条による定義 「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの（他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。）をいう。
これで、もし漏れても、俺、ウンコ漏らして臭いけど、パンツから出てないからいいよね？というレベルにはなった。はず。
万が一漏れても大丈夫！と書いたけど、そもそも漏らすなというお話になる。色々調べた結果、以下の対策をほどこした。
・当初jQuery側でSQL組み立ててPHPに渡してたので、これだと任意のSQLが実行できて漏らし放題なのでやめる。
・GETとかPOSTでDBに渡すパラメータを扱ってる場合、ちゃんとエスケープする。
例えばログイン認証するPHPで、GETメソッドでフォームからデータを取得するような場合、
$id=$_GET['id'] $pwd=$_GET['pwd'] $sql="select * from ユーザーテーブル where uid='$id' and pwd='$pwd'
とかやってると、login.php?id=admin'&pwd=' OR '1'='1とかパラメータを渡されるとあら不思議！
select *from ユーザテーブル where uid='root' and pwd='' or 1=1
で、誰でもログイン出来ちゃう！ので、mysql_real_escape_stringでエスケープしたり、渡されたパラメータが想定した値かどうか（例えば数値かどうか、とか）のチェックをいれたりする。
・保存するデータにタグやJavascriptを埋め込まれないように、保存されたデータを出力する場合はPHP側でhtmlspecialchars関数使ってエスケープするようにする。
こんな感じでお漏らし対策をした。間違いがあったら教えて欲しい。
ちなみに出来上がったサイトはこれ。
残念だけど、SQLインジェクションとか、セッションキーのコリジョンとかだったら、まだわかるが・・・
URLをちょっと変えただけで他人のデーターがみえちゃいますとか、どんだけだよ。
残念だが、この業界でプロを名乗るなら、このレベルは、知っている範囲で、あきらかな過失だよ。
サービスするんだから、専門家を雇えよ。当たり前だが、作る業者と検査する業者は別にしろよ。知らないんだったら。
何回も言ってるけど、今回の被害者は情報漏洩された人たちで、加害者はあくまで、サービス主体のPCソフト販売業者。
僕もだまされたんです、知りませんてのは、普通は・・・情状酌量の余地はあるけど・・・、
責任をとるのはあくまでも、PCソフト販売業者。PCソフト販売業者が別途制作会社を訴えるかどうかはそら、PCソフト販売業者の話で、ユーザーには関係ない。
つか、メールベースのシステムなら問題なかったのに、知識もなく、予算もなく、ツテもなく、Web化してコケたんだろ・・・どんだけだよ。
データーはログインして、セッションを持ちましょうとか、本にも初歩として書いてあるだろうと。さすがに、このレベルは酷いよ。
程度の問題だよ、程度の問題。
他にもパスワード平文で保存して流出とか svnのバックアップをサーバーにあげて流出とか パスワードをEXCELで保存して流出とか
頭痛いすぎるんだよ、最近の事件は・・・ハッキングですらねーだろと
しかしなぁ、
世の中には、パスワード一覧をEXCELファイルで作っちゃって、まちがってメールで関連先に送付しちゃって大問題っていう
それでいて、操業停止になるくらい、ユーザーが離れるわけでもないんだぜ？
そりゃぁ、セキュリティーなんて向上しないし、みんな無視するよなぁ
安かろう悪かろうで、そういう業者に発注するからそういうことになるんだが・・・
真面目にセキュリティーに取り組んでる奴がバカをみる・・・
嫌な時代だよな。
ちなみにな・・・
http://mag.wb-i.net/2010_04_02.html
対処策が・・・
１．metaタグの挿入（noindex,nofollow,noarchive）
２．USER_AGENTよるSpiderの排除
なんつーかな。
そもそも、セッション持って、外部から見られないように対策すべきであって、クロールされなきゃ良いって問題じゃないと思うんだが？
それにmetaタグよりrobots.txt使えば早いのに・・・とか、突っ込みどころ満載。
これを無しで販売したそのマインドがすばらしいし
それを購入した方のマインドもすらばらいい。
起きるべくして起きた事件としかいいようがない。
つーか、こんな初歩の初歩にひっかかるようじゃ、
真面目な攻撃食らったら簡単に個人情報吐き出しそうだな・・・このプログラム。
SQLインジェクションに感染したりして・・・ｗ
私は単なる一増田でしかないのだが、なんとなく今日を増田的情報セキュリティの日とすることに決めた。
なぜって、今日は、年末年始という忙しく、そして狙われやすい時期をはさみ、2月2日からきっかり103日前だからである。
決して、はまちちゃんとエガミ君のやり取りがあったとか、増田はセキュリティ関連の話題に乏しいとか思ったからではない。
さて、一口にセキュリティといっても、その幅は広い。まずは定番から攻めるのが定石であろう。何が定番なのかについては、例えば「Webアプリ脆弱性オタがふつーのSEの彼女に脆弱性世界を軽く紹介(ry」などが参考になるだろう。
しかし、たとえば「初心者はPHPで脆弱なウェブアプリをどんどん量産すべし」といったような初心者には、まずは10というよりも1から脱初心者していただくのがよいであろう。
そんなわけで、今年のテーマはXSSとする。繰り返すが、はまちちゃんとエガミ君のやり取りがあったとか、XSS以外のネタが少ないとかではない。
さて、このように、今年のテーマはXSSとなった。それではXSSとは何か、どのように起き、どう対処すればよいのか、そのような実例ちょうど良いエントリが「エガミくんの脆弱性のやつ」である。
さらに、このエントリをよんで、実際に「XSSしたい＞＜」と思った人に読んでいただきたいのは「今昔さっき物語」であろうか。
さて、非常に簡単にXSSについて書いたが、このXSS、実はその他のさまざまな脆弱性の基礎でもある。
出力がHTMLならXSSだが、SQLならSQLインジェクションだし、シェルならコマンドインジェクション、メールヘッダならメールヘッダインジェクション等々になりえる。とくに、初心者にとってシェルは予想外のところで使われているから、気をつけよう。
その他セキュリティに関心があればsecurityタグをお勧めしたい。セキュリティよりもsecurityの方が濃いのである。
まあ、どのくらいの数の脆弱性オタがそういう彼女をゲットできるかは別にして、
「オタではまったくないんだが、しかし自分のオタ趣味を肯定的に黙認してくれて、
その上で全く知らない脆弱性の世界とはなんなのか、ちょっとだけ好奇心持ってる」
ような、ヲタの都合のいい妄想の中に出てきそうな彼女に、Webアプリ脆弱性のことを紹介するために
（要は「脱オタクファッションガイド」の正反対版だな。彼女に脆弱性を布教するのではなく
相互のコミュニケーションの入口として）
あくまで「入口」なので、時間的に過大な負担を伴うような図解などは避けたい。
できれば、秋葉原とか筑波とかから突っ込みがはいるような微妙な奴も避けたいのだけれど、つい選んでしまうかもしれない。
あと、いくら脆弱性的に基礎といっても古びを感じすぎるものは避けたい。
プログラム言語オタがCOBOLは外せないと言っても(いましたね)、それはちょっとさすがになあ、と思う。
そういう感じ。
彼女の設定は
セキュリティは専門でもなんでもないが、クロスサイトなんちゃらとか、SQLなんとかくらいは聞いたことがある。
サブカル度も低いが、頭はけっこう良い
という条件で。
まあ、なんで一番がSQLインジェクションじゃないんだよとも思うけれど、たいていのWebアプリに必ずあるという普遍性(日本語変か?)とか、文字コードネタのバリエーションとか、DOMが絡んでわくわくするとか、Same Origin Polic何じゃそりゃという点では外せないんだよなあ。長さも3文字だし。
ただ、ここでオタトーク全開にしてしまうと、彼女との関係が崩れるかも。
この情報過多な脆弱性について、どれだけさらりと、嫌味にならず濃すぎず、それでいて必要最小限の情報を彼女に
伝えられるかということは、オタ側の「真のコミュニケーション能力」の試験としてはいいタスクだろうと思う。
アレって典型的な「オタクが考える一般人に受け入れられそうな脆弱性（そうオタクが思い込んでいるだけ。実際は全然受け入れられない）」そのもの
という意見には半分賛成・半分反対なのだけれど、それを彼女にぶつけて確かめてみるには
一番よさそうな素材なんじゃないのかな。
「Webアプリの専門家からいえば、この二つはアプリネタじゃないと思うんだけど、率直に言ってどう？」って。
侵入先のファイルが見えてしまうというハッカー的なものへの憧憬と、これによる逮捕者がいるという法的な考証へのこだわりを
彼女に紹介するという意味ではいいなと思うのと、それに加えていかにもマニアックな
「よく眼にするけどあまり実害の思いつかない」/etc/passwd
「滅多に見られないけど、見つけたらゾクゾクする」/etc/shadow
の2ファイルをはじめてとして、オタ好きのするファイルを世界に公開(流出?うわ、日本語間違いが怖い)しているのが、紹介してみたい理由。
たぶん秋のDK収穫祭を見た彼女は「これCSRFだよね」と言ってくれるかもしれないが、そこが狙いといえば狙い。
そして、われらがアイドルはまちちゃんの紹介のおかげで、この脆弱性が日本で大人気になったこと、
「やっぱりWebアプリの脆弱性は個人情報DBなんかがあるサイトのものだよね」という話になったときに、そこで選ぶのは「SSIインジェクション」
でもいいのだけれど、そこでこっちを選んだのは、この脆弱性がふつーのホームページなどでも本当によく見つかるくせに、意外に問題視されていないレアっぽさが好きだから。
断腸の思いでJavaMailのAPIがTo欄やFrom欄に改行チェックいれているのに、なぜかSubject欄だけチェックがされてなくて脆弱性の原因になるかもって中途半端さが、どうしても俺の心をつかんでしまうのは、
その「チェックする」ということへの躊躇がいかにもオタ的だなあと思えてしまうから。
ほかのメールAPIでもチェックが不十分なものはあるし、そもそもsendmail呼び出すときはチェックはアプリ側でやるしかないとは思うけれど、一方でこれが
Microsoftだったら意外にきっちりセキュアに仕上げてしまうだろうとも思う。
なのに、安全なAPIを使わずに(知らずに?)脆弱性を混入してしまうというあたり、どうしても
「自分の過去から知っている書き方でないと書けないプログラマ」としては、たとえ脆弱性混入した奴がそういうキャラでなかったとしても、
親近感を禁じ得ない。脆弱性の高危険度と合わせて、そんなことを彼女に話してみたい。
今の若年層でディレクトリリスティングによる個人情報漏洩事件をリアルタイムで見聞きしている人はそんなにいないと思うのだけれど、だから紹介してみたい。
SQLインジェクションよりも前の段階で、個人情報の漏洩規模とかはこの脆弱性で頂点に達していたとも言えて、
こういう危険の高さが経産省あたりの個人情報保護ガイドラインにのっていたり、というのは、
別に俺自身がなんらそこに貢献してなくとも、なんとなく脆弱性好きとしては不思議に誇らしいし、
いわゆるインジェクション系でしか脆弱性を知らない彼女には見せてあげたいなと思う。
UNIXシェルの「セミコロン」あるいは「バッククォート」をオタとして教えたい、というお節介焼きから見せる、ということではなくて。
「ホワイトリストで対策すると安全なんだけど敢えてエスケープを究めたいマニア」的な感覚がオタには共通してあるのかなということを感じていて、
だからこそ佐名木版『セキュアWebプログラミングTips集』は20ページ以上もかけてOSコマンドインジェクション対策の説明しているのは、エスケープ手法以外ではあり得なかったとも思う。
「侵入先のコンピュータでコードが動いてこそなんぼ」というクラッカーの感覚が今日さらに強まっているとするなら、その「クラッカーの気分」の
源はOSコマンドインジェクションにあったんじゃないか、という、そんな理屈はかけらも口にせずに、
単純に楽しんでもらえるかどうかを見てみたい。
これは地雷だよなあ。昔だったら筑波方面、今だったら秋葉原方面から火のような「hiddenは危険脳」ブクマがつくか否か、そこのスリルを味わってみたいなあ。
こういう昔のIPA風味の解説をこういうかたちでブログ化して、それが非オタに受け入れられるか
突っ込みを誘発するか、というのを見てみたい。
9本まではあっさり決まったんだけど10本目は空白でもいいかな、などと思いつつ、便宜的にSQLインジェクションを選んだ。
XSSから始まってSQLインジェクションで終わるのもそれなりに収まりはいいだろうし、カカクコム以降のWebアプリ脆弱性時代の原動力と
なった脆弱性でもあるし、紹介する価値はあるのだろうけど、もっと他にいい脆弱性パターンがありそうな気もする。
というわけで、俺のこういう意図にそって、もっといい10パターン目はこんなのどうよ、というのがあったら
教えてください。
「駄目だこの増田は。俺がちゃんとしたリストを作ってやる」というのは大歓迎。
Inspired by アニオタが非オタの彼女にアニメ世界を軽く紹介するための10本
まぁね??、「時間ないから！社内システムだから！」でヌルーされる可能性は十分にあるよね。
もしくはバグ報告受けた開発側の担当者が「SQLインジェクション？何それおいしいの？」って状態だったら、何事もなかったものとして処分されるかもｗ
実証コード添付で投げるのが一番理想だが、そんな事を本番環境でやったら牢獄行きになる罠
# や、誇張じゃ無しに今のバイト先は「不正アクセスです＞＜」とか言って迅速に警察に通報してくれそうな所なんです（汗
ここまで書いてふと思ったけど、社内でしか使わないシステムに脆弱性が見つかった場合、どんな体制だったら理想的なんだろ？
脆弱性を報告した人に「修正したかどうか」のレスポンスがあれば(自分的には)ベターだけど、
でかい企業だと伝言ゲームをしている最中に有耶無耶になってしまいそう。
# しかも自分の立ち位置は超末端だから連絡すら、そもそも伝言する対象にすらなってなさそう…orz
つい最近、社内の重要なシステムに「'」を入れると、SQLサーバから「シンタックスエラー」とか言われる欠陥を発見してしまった。
っていうかこれってSQLインジェクションなんじゃ…orz
あの部分には「'」を入れることは滅多にないから気付きにくい。
そしてこのシステム、恐らくは完全にイントラ用。
社内にはクラッキングできる奴もいなそう。
仮にいたとしても、盗んだ情報を非常に持ち出しにくい(怪しい操作をする人間を特定しやすい)運用をしている。
けどこれってどうなんだ。
日頃から「情報漏洩しないようにがんばろー＞＜」と派遣バイト・派遣社員・正社員含めてそこに勤務してるみんなが頑張ってる。
けど、これを無茶して(もしくは脅迫などして無茶させて)悪用する奴が現れたら一巻の終わりだよ。
※ちなみに最低でも毎日300人はそのシステムを操作しているし、その問題となる部分は権限上1000人以上の人間が操作可能と思われる。
一応、直属の上司に「これ、ヤバイエラーかもしれないんで、開発元に報告しておいてください」と報告しておいた。
諸君 私は脆弱性が好きだ
諸君 私は脆弱性が大好きだ
PHPが好きだ
XSSが好きだ
SQLインジェクションが好きだ
CSRFが好きだ
UTF-7が好きだ
expressionが好きだ
Webで
LiveHTTPで
Filemonで
Regmonで
OllyDbgで
Perlで
セキュリティに関して口うるさく言っているサイトの脆弱性をいとも簡単に見つけるのが好きだ
大企業のサイトがGoogleによって脆弱性を発見された時など心が踊る
Perlを馬鹿にしていた奴のアカウントを乗っ取った時など胸がすくような気持ちだった
粘り強い同業者がMS Officeのシリアル認証と格闘している様が好きだ
PHP覚えたての野郎共が続々と脆弱性を作り出していく様など感動すら覚える
気に入らない奴のPCにトロイの木馬を忍ばせ奴の個人情報がWinnyネットワークに流れてゆく様などはもうたまらない
精魂込めて更新していたであろうWikiを滅茶苦茶にするのが好きだ
必死に守るはずだった同業者が次々に逮捕されてゆく様はとてもとても悲しいものだ
FBIに追いまわされ泥棒の様に捕まる恐怖と戦うのは屈辱の極みだった
諸君 私は攻撃を地獄の様な攻撃を望んでいる
諸君 私に付き従うクラッカー諸君
君達は一体何を望んでいる？
更なる攻撃を望むか？
情け容赦のない糞の様な攻撃を望むか？
鉄風雷火の限りを尽くし三千世界の鴉を殺す嵐の様な政府との闘争を望むか？
『攻撃！ 攻撃！ 攻撃！』
よろしい ならば攻撃だ
我々は渾身の力をこめて今まさに振り降ろさんとする握り拳だ
だがこの暗い闇の底で半世紀もの間堪え続けてきた我々にただの攻撃ではもはや足りない！！
大攻撃を！！
一心不乱の大攻撃を！！
我々はわずかに小数
ならば我らは諸君と私で総兵力100万と1人の集団となる
我らを忘却の彼方へと追いやり、眠りこけている奴らを叩きのめそう
髪の毛をつかんで引きずり下ろし 我々の方が強いことを眼(まなこ)をあけて思い出させよう
連中に恐怖の味を思い出させてやる
連中に進入される恐怖に怯えながら眠る夜を過ごさせてやる
連中に我々の技術を思い知らせてやる
天と地のはざまには奴らの哲学では思いもよらない事があることを思い出させてやる
世界を恐怖に陥れてやる
なんで悩んでるのかもわからん・・・
select ** from 都道府県 tb1 left outer join 地方 tb2 on tb1.地方コード = tb2.地方コード order by tb1.地方コード
でいいんじゃないの？？
地方コードで引きたいってこと？
select ** from 地方 tb2 left outer join 都道府県 tb1 on tb1.地方コード = tb2.地方コード where tb2.地方コード = 北海道 order by tb2.地方コード
みたいなことか？
CREATE function get_地方名(w_地方コード varchar(32)) RETURNS varchar(64)
RETURN
地方名
from
地方
where
;
こうやっといて、
select **, get_地方名(地方コード) 地方名 from 都道府県 tb1 order by tb1.地方コード
こんな感じにやるとか、
いろいろやりかたはあるんでねぇの。
もちろん一覧で取得したいなら外部結合のほうがいいにきまっとる。
んじゃ！そんなわけでがんばって！！
SQLインジェクションには気をつけないと怖い増田に怒られるぞ！
追記。
脳内解釈してちょ
**
もちろん、反論もあるだろう。たとえば「Defending PHP」とか。
でも、個人的にはやはり否定側の方が筋が通ってる印象かな。
特に「rubyは初心者に学びやすい(と言われていることが問題である)」という部分に共感する。 rubyは初心者に簡単かもしれないが、初心者による手を抜いたWebアプリケーションは rubyが作られた当初はともかく、現代では害悪ではないだろうか。
cgi.rbならではの理由がないわけではないことはわかる。標準添付されているとか、デプロイが簡単とか。
でも、「標準添付」を一般公開されるWebアプリケーションを開発するためのライブラリとしての利点にするのはもうやめようよ。
追記
「どのライブラリで書いてもおかしなコードを書く奴は書く」という指摘もあった。それは言うまでもない事実ではある。そこには反論しない。
が、本当に問題なのは、世の中には「おかしなコードを書くことを助長するライブラリ」もあるという点だ。で、そういうライブラリにはおおむね「標準添付」というラベルがついている。どういうわけだか。
たぶん、「初心者がおかしなコードを書くのをじゃましない」とかあるいは「初心者っぽいコードを積極的に支援する」から、「標準添付」って呼ばれるんだろう。もしくは「設計者がまだ初心者」とか。
そういうライブラリが存在しちゃいけないとは言わないけど(人に迷惑をかけない範囲で)、ここ半世紀のライブラリの進化をないがしろにするのはもったいないと思うな
$_POST = array_map('htmlspecialchars', $_POST);
$_GET = array_map('htmlspecialchars', $_GET);
$HTTP_COOKIE_VARS = array_map('htmlspecialchars', $HTTP_COOKIE_VARS);
//$_SERVER = array_map('htmlspecialchars', $_SERVER);
$_SERVER['HTTP_USER_AGENT'] = htmlspecialchars($_SERVER['HTTP_USER_AGENT']);
$_SERVER['PHP_SELF'] = htmlspecialchars($_SERVER['PHP_SELF']);
//改行コード→改行タグ
function del_tag($str) {
return $str = str_replace("\r\n", "<br>", $str);
}
$_POST = array_map("del_tag", $_POST);
$_GET = array_map("del_tag", $_GET);
$HTTP_COOKIE_VARS = array_map('del_tag', $HTTP_COOKIE_VARS);
$_SERVER['HTTP_USER_AGENT'] = del_tag($_SERVER['HTTP_USER_AGENT']);
$_SERVER['PHP_SELF'] = del_tag($_SERVER['PHP_SELF']);
//タブ除去
function del_tab($str) {
return $str = str_replace("\t", "", $str);
}
$_POST = array_map("del_tab", $_POST);
$_GET = array_map("del_tab", $_GET);
$HTTP_COOKIE_VARS = array_map('del_tab', $HTTP_COOKIE_VARS);
$_SERVER['HTTP_USER_AGENT'] = del_tab($_SERVER['HTTP_USER_AGENT']);
$_SERVER['PHP_SELF'] = del_tab($_SERVER['PHP_SELF']);
セキュリティ全然詳しくないだけども・・・
例えばこんな感じのファイルを置いてから、最初に
require 'secure.php';
そのファイルをincludeするように先頭に書いておくだけで、いろんなサニタイズとかを一気にやってくれるような仕組みってないのかな（SQLインジェクションとやらもちゃんと防げるようにして）。
無ければ増田でみんなで作る程度の価値はありそうなものだと思う。
root権限奪取とか、SQLインジェクション持ち出されても、はいそうですねとしか言いようがない。
あと PHPだから安全、みたいな事を言うのは必ずしも正しくないし、有害なのでやめれ。
そんな事だれも言ってない。
というお話じゃねえの。PHPに限らず、初心者が公開するのはまずい。
未知の脅威って何だ？ インジェクション対策とセキュリティアップデートくらいなら少し覚えればできるでしょ。
そもそも何かを作り上げることができる人というのは非常に少ない希少種なのに、
そこに入ろうとする前途ある人達のモチベーションを使用言語がどうこうと、
挫こうとするのはなんか憤りを感じるよ。
PHPというツールを批判しただけなのに、なんでそういう誤読になるのか。誰も挫こうとはしてないでしょ。一部の初心者の人たちが勝手に被害的になってるだけ。
同意だよ。
初心者が本当に注意しなければいけないのは、スクリプトの脆弱性よりもサーバーのセキュリティ。
PHPなら大抵どこのレンタルサーバーも利用可能なので殆ど問題がない。
なにがいいって現段階においてはPHPは非常に多くの人に使われている。
だからもし見当違いなことをやっていたら注意してくれる人がいっぱいいる。
そして何よりも大きいのはサーバー運営業者などがノウハウを吸収しているということ。
PHPでシステムコマンドなんかは大体止められているしRFIなんかの攻撃に対しても不正なファイルが埋め込まれたりすたら通報してくれるところもある。
現段階のRubyでそれができるだろうか？
大手のレンタルサーバーでさえまだ設定があやふや。
そのままじゃ動かなかったりしている。
じゃぁ自前サーバーならいけるのかというと、正直初心者には無理なんじゃないの？
Mongrelあたりを入れて、あれ、これメモリ漏れてねぇ？とかそういう心配をしたり、24時間監視できるわけがない。
まだ「いいえ」なんじゃないの？
Rubyをちゃんとできる人や教えられる人はまだ少なすぎる。
PHPをぐだぐだ言うひとはちゃんとできるひとなのかな？
どうなのよ？
まあ異論はあるかもしれないが。。
あと、こっちは、一般的に同意をえられるとおもうんだけど、
スクリプトが垂れ流す脆弱性よりもroot権限のっとられたマシンの方が怖くね？
んでもって、遥かに有害だよね。
そんなに言うならSQLインジェクションの穴のひとつでも見つけて報告してごらんよ。
SQLインジェクションなんて、DBに接続ができるようなレベルになれば最近のマニュアル本には当たり前に書いてあるじゃない。しかもこれは何もPHPに限った話しじゃないじゃない。
穴なんて時間の経過とともに増えるんだから、メンテナンスされてないサービスのほうが怖いわけですよ。
ローカル言語やサーバー使ってそのままになってしまうほうが最悪なんじゃないかな。
もし、素人がぐだぐだにつくったPHPサービスとかで問題があるとすれば・・・
・SQLインジェクションで中の情報が漏れる（そんなサービスに漏れて大切な情報登録するなよ）
・メール送信系でヘッダー偽装でスパムの踏み台にされる（これは意外と多いかもしれないね）
・クローラーが他のサーバに負荷をかけまくる
まあどれもPHP”だから”というわけでもないよね。
97年頃にはperlだって掲示板やアップローダーだって穴だらけだったじゃない。
coderedがでるまでiisで建ってたサーバーだって山ほどあった。
そのころにはSQLインジェクションに対応していないサイトは本当に簡単に見つけられた。
初心者は主流からはいるのがいろんな意味でみんなのためじゃない。
今の主流はphpということでいいんじゃないの？
PHPは発展期
RonRは成長期（すくなくともあと1年ぐらいは）
perlは爛熟期
あとは・・・
pythonからColdFusionのにおいしてない・・・？
あと、なんかLLってあったっけ？
curlがなんかいまさらだけど脚光をあびるような予感がしている。
ところでさ、
PHPを批判しているような人はPHP6の仕様とかちゃんとフォローしてるのかね？
そもそも何かを作り上げることができる人というのは非常に少ない希少種なのに、
そこに入ろうとする前途ある人達のモチベーションを使用言語がどうこうと、
挫こうとするのはなんか憤りを感じるよ。
Matzみたいな人がそれをやってどうするんだよとか、ちょっと思った。
おいおい。
んなわけない。少なくとも、積極的にこれを勧める奴はDQN。CSRFを知らないわけじゃない踏み台にされるケースがある事くらい分かるでしょ。あと、Matzの意見にも反していると言っておく。
_ まつもと (2008-01-29 14:13)
愉快犯もそれなりに居ますから、「本当にまれ」と断言する勇気は私にはありません。教育はぜひ閉じた環境で行っていただきたいものです。
(略)
_ まつもと (2008-01-29 18:46)
(略)
いざ問題が起きてから「想像してなかった」とかいうくらいなら、最初から外につながったWebアプリなんて書かない方がよいと思います。そういう意味で「舐めるな」と書いたわけで。Webアプリを書く人はちゃんと「外」を自覚した方がよいと思いますが、初心者でそれができてたらかなり奇跡的。
あとこれ何言っているの？
それに、「未熟なうちは公開するな」とか言うと、「自分、未熟ですから」とか言って秘密主義を貫くことにもなりかねない。
ソースだけネットで公開すればいいじゃん。それが嫌なら、内輪でサービスを動作させて切磋琢磨すればいいじゃん。
インターネット上で、動作するサービスとして公開するな、と一貫して言っている。そんな事も分からんの？
あと、セキュリティがわかるというのをどういう意味で使ってるのかわからないけれど、実行環境に関するもののみ考えても、セキュリティ問題は日々大量に発覚しているし、
少なくとも、ネタがPHPなので、この場合のセキュリティはXSSやCSRFやらSQLインジェクションやらが対象でしょ。これらの問題の根本は明らか。まともな開発者なら誰でも知ってること。実行環境については、とりあえず定期的にアップデートするものと覚えていればよい。
もし上記のようなWebセキュリティについてそういう認識で居るのなら、即刻改めた方がいいよ。問題の切り分けをする気持ちができてないんじゃないかとおもう。これは完全に邪推で、そうでなければいいと思うけど。
http://www.rubyist.net/~matz/20080126.html#p04
趣味でやってるプログラミング初心者の立場で言わせてもらう。だいたいな、あんたらプロのプログラマが小難しい顔してセキュリティセキュリティ言うもんだから初心者プログラマのセキュリティ意識がまったく向上しないばかりか、よけいに低下するんだよ。ごちゃごちゃ言われたり叩かれるのはイヤだけど、眼前の問題はプログラムで解決したいってヤツは耳塞いで黙ってPHPでやりたいようにやるんだよ。何が「楽しいRuby」だよ。「Webアプリケーションをなめるな」ってその時点でもう全然楽しくねーだろが。
それでこれだよ。
http://d.hatena.ne.jp/essa/20080130/p1
もう萎縮萎縮！初心者超萎縮ですよ。「あーセンコーうぜー。隠れてタバコ吸おう」って高校生の心境だよ。難しい顔して訳知り顔でかっこつけてるヤツばっかりじゃねーか。おれだって趣味でやるとはいえセキュリティの事はけっこう勉強したよ。XSSだのSQLインジェクションだのなんだかんだ。でもこの手の説明って本当に初心者には分かりにくい説明ばっかりで、高木浩光にしたって長い上に何言ってるのかさっぱり分からない。肝心の初心者に声が届いてなくて、わかってるもん同士で「うむうむ、セキュリティは大事ですなぁ」って仲間ごっこしてるだけじゃねーか。阿呆か。そんなに大事なら分かりやすく説明してみろっての。
だいたい、初心者がお手軽にPHPで作ったウェブアプリのせいで実際にどんな被害が出たんだよ。具体的に。おれの知ってる限りじゃこの手のウェブアプリ攻撃で本当にイヤだな、と思ったのははまちやのせいでダイアリー勝手に更新されたとか、それくらいしか記憶に残ってねーよ。それだって作ったのはプロじゃねーかよ。確率的には低い「初心者がPHPで作ったウェブアプリの危なさ」をさんざん煽ってよ？初心者プログラマ萎えさせて何が楽しいんだよ。くだらねえ。
だからおれは全世界の初心者プログラマおよび潜在的プログラマにこう告げる。PHPでどんどん作れ。Perlとかダメ。クセありすぎ。RubyとかJavascriptはオブジェクト超難しい。だからPHP。セキュリティとか気にするな。そんなもん気にして途中であきらめるよりお前が実際に何か作る事の方が大事だ。もし万が一脆弱性突かれて問題になったら、そんときゃ謝れ。プロが作ったもんだって攻撃される時はされるんだから。反省して、そこで初めてセキュリティの勉強しろ。痛い目見たらイヤでも身に付くから。怖がって最初からやらないより、なにかやらかして学ぶ方が100倍いいに決まってる。
ふと思いついてSQLインジェクションについて調べてみたが、一番の対策にprepared statementを挙げてない記事ばかりなのはなんでだ？
うわああああ！
そんなの久々に見たよ！
久々ってのはさ、昔 IIS 4.0 と SQL Server 2000 を使った既存システムの保守の仕事をやった時に近いものなら見たことがあるんだ。日本語カラム名とか SQLインジェクションとか。それでも HTML ソース読んだだけでここまで色んなことがわかるおもしろシステムは生まれて初めて見たけど。
そんなことよりこのサーバーを管理してるとこのこれ。
http://www.yes.ne.jp/service/aspsv.html
やっべ、ごめん、とてもじゃないけど任せられない。
このページにおける大なり小なり面白いところ
ちなみにこのページ、イエス・インターネットのトップページのよく見えるところからリンク張ってある生きたページだよ。いや、このウェブサイトそのものが無縁仏状態と見た方がいいのかも知れんが。他のページも楽しめるので暇潰しにどうぞ。