タグ

sql injectionに関するpochi-pのブックマーク (12)

  • 「滋賀の病院、セキュリティ弱い」 サーバー侵入容疑の香川の高校生が示唆か - 産経WEST

    今年9月に滋賀県内の病院のサーバーに侵入し、管理者のIDとパスワードを不正に入手したとして、滋賀、岡山両県警は2日までに、不正アクセス禁止法違反の疑いで、香川県さぬき市の高校3年の少年(18)と、茨城県古河市の高1の少年(15)を、それぞれ逮捕した。 捜査関係者によると、2人に共謀関係はないが、会員制交流サイト(SNS)で連絡を取り合っていた。香川の高校生が先に病院のサーバーに侵入し、「ここのセキュリティーは弱い」と茨城の高校生に教えた疑いがある。 香川の高校生は「3年前から多くの施設に侵入した。他人のクレジットカード情報を取り、買い物をするのが目的だった」と供述。茨城の高校生も「個人情報を盗み、お金にしようとした」と話している。 逮捕容疑はそれぞれ9月7日、自宅のパソコンから滋賀県の病院のサーバーに侵入、IDを不正取得した疑い。ハッキングの手口の一つで、プログラム言語「SQL」に不正な指

    「滋賀の病院、セキュリティ弱い」 サーバー侵入容疑の香川の高校生が示唆か - 産経WEST
  • http://www.jellyfish-novels.net/2016/11/sql.html

    http://www.jellyfish-novels.net/2016/11/sql.html
    pochi-p
    pochi-p 2016/12/06
    素人にSQLインジェクション説明するなら「B'zやI'veやL'Arc-en-CielがDBに登録出来ない致命的欠陥。致命的欠陥だから攻撃も可能。当たり前の対応すれば自然と攻撃も防げる」だけで良い気が。
  • SQLインジェクション対応しないの? - masalibの日記

    ここ最近はゲーム仕事に忙しくてブログの更新をさぼっていました m(_ _)m 外注さんといっしょに仕事するようになって 一番ビックリしたのは SQLインジェクション対応していない事 マジで・・・ フレームワークの関数が用意されているのにそれをつかわずに 独自でSQLを書いている・・・・ 気がついたのは外注さんが作ったソースをもとに 似たような機能を作ろうとしたらビックリ いやいやいや・・・・ フレームワークに従うべきだろう・・・ あとから入ったプロジェクトだけにいまさら戻れないけど インフラエンジニアとしてSQLインジェクションをいれていないのは許せない!! 全プログラムをコードレビューしないといけないとか マジ悲しい・・・

    SQLインジェクション対応しないの? - masalibの日記
    pochi-p
    pochi-p 2016/06/09
    音楽系のシステムであれば「お前稲葉さん&松本さんに喧嘩売ってんの!? B'zを全否定なの!? 戦争なの!?」って言ってあげましょう。(恒例のネタ)
  • SQLインジェクションについて。SQLインジェクションの実例として書籍に記載されていたことで不明点がありましたので、教えてください。 ... - Yahoo!知恵袋

    SQLインジェクションについて。 SQLインジェクションの実例として書籍に記載されて いたことで不明点がありましたので、教えてください。 SQLインジェクションについて。 SQLインジェクションの実例として書籍に記載されて いたことで不明点がありましたので、教えてください。 ①ウェブアプリケーションによるSQL文の組み立てが、 下記として、シングルクォーテーションの中にユーザーからの 入力値を入れる。 select * from user where id = ' ': ② ①のユーザーからの入力値として、下記を 入力する。 ' OR 'A' = 'A' -- ②の入力値の コメント「--」は何故必要なのでしょうか? 下記でもよいのではないでしょうか? ' OR 'A' = 'A 何故わざわざコメントをつけているか 教えていただけますでしょうか?

    SQLインジェクションについて。SQLインジェクションの実例として書籍に記載されていたことで不明点がありましたので、教えてください。 ... - Yahoo!知恵袋
  • 【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方

    SQLインジェクションを・・・駆逐してやる!! この世から・・・一匹残らず!! (PHPカンファレンス2015) Read less

    【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方
    pochi-p
    pochi-p 2015/10/08
    いつぞやどっかで「'SQL文字列型'と'文字列型'を区別して、文字列演算子を使えなくしちゃいましょう」って言ってたのと根っこは一緒の発想かな? 最終目標は分かるけど、現状の選択肢はどれだけあるのだろう…?
  • SQLインジェクション対策もれの責任を開発会社に問う判決

    ポイントは下記の通りです。 X社(原告)はセキュリティ対策について特に指示はしていなかった 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった(2010年1月29日) X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた(2010年9月27日)が、その後X社は改良の指示をしなかった 以下の脆弱性その他が認められた システム管理機能のIDとパスワードが admin/password であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能(ディレクトリリスティングと意図しないファイ

    pochi-p
    pochi-p 2015/01/23
    「SQLインジェクションは(ライブラリの不具合でもない限り)当たり前に対策しようよ」とは思うけど、色々もにょる部分も…。 / とりあえずSQLインジェクション放置の糞XXを脅す材料として役立たせて頂こうか。
  • DeNA Engineering - DeNAエンジニアのポータルサイト

    技術を活かし、新しい価値を創造する DeNAのエンジニアは、想像を超えるDelightを届けるために何ができるかを考え、技術力と発想力で新しい価値を生み出しています。 多様な専門性を持ったエンジニアが切磋琢磨し、互いに刺激し合える環境や制度がさらなる成長へとつなげます。

    DeNA Engineering - DeNAエンジニアのポータルサイト
    pochi-p
    pochi-p 2014/07/05
    やっぱりプレースホルダって型指定出来た方が良いよね。少なくともSQLを記述した時点でSQL側の型は確定するんだし。
  • 教訓はなぜ生かされなかったのか:ITpro

    ワコールは2月8日から,約3カ月にわたって閉鎖していたECサイトを再開する。ワコールオンラインショップで不正アクセスによる個人情報漏えい事件が発生したのは2005年11月。5124件の情報の中にはクレジットカード番号が含まれた情報もあり,カード番号を不正使用された顧客の問い合わせにより発覚した。 不正アクセスに使用されたのは,SQL文を外部から送り込む「SQLインジェクション」と呼ばれる手口だ。このSQLインジェクションは,2005年5月に発生したカカクコムやOZmallなどへの不正アクセス事件でも利用されたとされる。 特にカカクコムの事件は全国紙でも報道されるなど,大きな話題になった。にもかかわらず,ワコールの事件は発生した。教訓は生かされなかったのだろうか。 実はワコールの担当者は,システムを開発したNECネクサソリューションズに対し,2005年7月末に問い合わせを行っていたという。「

    教訓はなぜ生かされなかったのか:ITpro
    pochi-p
    pochi-p 2013/12/29
    2006年時点の話でこんなんだったのか…。とはいえ「SQLインジェクション盛り込んだ」までは無理矢理目を潰れても、対応無視&放置は有り得ないのだけど…。「修正に高額費用をふっかけた」方がマシってどうよ。
  • SQL識別子は結局どうすればよいか

    今まで2回にわたって、SQL識別子のエスケープの問題を取り上げました。 間違いだらけのSQL識別子エスケープ SQL識別子エスケープのバグの事例 3回目となる稿では、SQL識別子の取り扱いに関する問題を整理して、一般的な原則を導きたいと思います。 SQL文が動的に変化する場合のSQLインジェクション対策 「間違いだらけの…」で示したように、識別子エスケープが必要な局面でそれが洩れていると脆弱性の要因になることがありますが、それは外部から指定したデータにより、SQL文の構造が変化してしまい、アプリケーションの要件にないSQL呼び出しがなされてしまうからでした。 しかし、「間違いだらけ…」の後半で示したように、識別子のエスケープだけではセキュリティ問題を防ぐことはできず、情報漏洩を招いてしまいました。外部から任意のSQL識別子を指定できることが問題という結論でした。 上記のように、アプリケー

  • 間違いだらけのSQL識別子エスケープ

    これから3回連載の予定で、SQL識別子のエスケープの問題について記事を書きます。SQL識別子のエスケープについてはあまり解説記事などがなく、エンジニア間で十分な合意がないような気がしますので、これらの記事が議論のきっかけになれば幸いです。 3回の予定は以下のとおりです。 間違いだらけのSQL識別子エスケープ(稿) SQL識別子エスケープのバグの事例 SQL識別子は結局どうすればよいか ということで、まずはSQL識別子のエスケープの失敗例について説明します。この失敗例はあくまで説明のために作ったもので、実際のものではありません。また、想定が「ありえない」と思われるかもしれませんが、意図的なものですのでご容赦いただければと思います。また、「間違いだらけの」というタイトルは、今回の題材が間違いだらけという意味であり、巷のSQL呼び出しがそうであるという意味ではありません。稿に登場する人物と団

  • 俺の脳内選択肢が、SQLインジェクション対策を全力で邪魔している — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something

    PHP Advent Calendar 2013 in Adventarの19日目です。昨日も私の「PDOでの数値列の扱いにはワナがいっぱい(2)」でした。 うっかりtogetterなんか見てしまい、無駄に時間を使ってしまったと後悔した上に混乱してしまい余計にわからなくなってしまった人もいるかも知れません。 そこで、せっかくの機会なので、SQLインジェクション対策について、現在の私の考えをまとめておこうと思います。 選べ ①SQLインジェクション対策にプリペアドステートメントを使う ②SQLインジェクション対策にエスケープを使う もし、上記のような選択にはまってしまったら、あなたのSQLインジェクション対策は、現実的には、ほぼ100%間違っていると言えるのではないでしょうか。プリペアドステートメントとエスケープは、このような対立構造にはありませんから。 なお、この記事は、SQLインジェクシ

  • 書式文字列によるSQLインジェクション攻撃例

    以下のようなコードがあり、nameは画面入力なのでSQLインジェクションが起こるのでは? と作成者に確認したところ、"%s"してあるから大丈夫との返事をもらいました。 ネット調べるとmysql_real_escape_stringでエスケープしてから"%s"で変換すれば大丈夫といった内容は見つけたのですが、mysql_real_escape_stringなど不要との返事をもらいました。 なぜ?と聞くとそういうものだとしか回答がありません。 ひどいですね。これは質問者が正しく、sprintfの%sで受けただけでは、SQLインジェクション脆弱性となります。 しかし、どうしてこのような間違った知識が出てきたのかと考えるに、数値を%dで受ける場合と混乱したのではないかと憶測しました。数値の場合、書式%dで受けていれば、仮に攻撃コードが入力されたとしても、%dで整数に強制変換されるので、SQLインジ

    書式文字列によるSQLインジェクション攻撃例
  • 1