SQLインジェクション対策もれの責任を開発会社に問う判決
ポイントは下記の通りです。 X社（原告）はセキュリティ対策について特に指示はしていなかった 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった（2010年1月29日） X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた（2010年9月27日）が、その後X社は改良の指示をしなかった 以下の脆弱性その他が認められた システム管理機能のIDとパスワードが admin/password であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能（ディレクトリリスティングと意図しないファイ
MySQL ユーザのホストをワイルドカードで指定してもlocalhostは含まれない
MySQL ユーザのホストをワイルドカードで指定してもlocalhostは含まれない 2012-02-04 MySQLをインストールしたので、とりあえずワイルドカードでホスト名を指定してテスト用のユーザを作成。 mysql> show databases; +-------+ | Database | +-------+ | information_schema | | hoge | | mysql | | performance_schema | | test | +-------+ 5 rows in set (0.00 sec) mysql> grant select on hoge.* to testuser@'%' identified by 'password'; Query OK, 0 rows affected (0.07 sec) mysql> select host,u
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
FuelPHP1.7、CSRF対策としてセキュリティトークンを使う｜マコトのおもちゃ箱 ～ぼへぼへ自営業者の技術メモ～
プログラミング言語や環境設定を中心としたパソコン関連の技術メモです。 主にシステム開発中に調べたことをメモしています。TIPS的な位置付けで、気が向いたときにちまちま更新していきます。
ロリポップでWordPressの改竄が拡がった理由
ロリポップでの大規模なWordPressサイトの改竄について http://lolipop.jp/info/news/4149/ ロリポップからのリリースでは、管理パスワードとログインへのアクセス制限の強化を推奨して、パーミッションの変更と全体のウイルスチェックを行うとしている。WordPressそのもののアップデートはマニュアルに方法が記載されているものの、リリースでは触れられていない。 このことから、被害が大きくなったのは、ロリポップの提供していたWordPressのインストール手順に問題があり、wp-config.phpなどのファイルのパーミッションが不適切だったためではないかと推察出来る。 いくつかのアカウントだけWordPressの管理パスワードが突破される、というのであれば、世界中でほぼいつでも起こっている。 もし、あるユーザーの管理パスワードが脆弱で推測することが出来てしまう
パスワード攻撃に対抗するWebサイト側セキュリティ強化策
Webサイトのパスワード認証を狙った攻撃が大きな脅威になっています。 Tサイト（プレスリリース） goo（プレスリリース） フレッツ光メンバーズクラブ（プレスリリース） eBook Japan（プレスリリース） My JR-EAST（プレスリリース） これらの事例のうちいくつか（あるいは全て）は、別のサイトで漏洩したIDとパスワードの一覧表を用いた「パスワードリスト攻撃（後述）」であると考えられています。パスワードリスト攻撃を含めて、パスワードを狙った攻撃が成立してしまう原因は、利用者のパスワード管理に問題がある場合が多く、攻撃を受けたWebサイト側には、直接の責任はないケースが多いと考えられます。 しかしながら、 大半の利用者はパスワード管理に興味がない パスワード認証を採用している理由は、コスト上の理由、すなわちサイト側の経済的な事情 インターネットが「とても危険なもの」となるとネット
セキュリティアナリストのつぶやき
2022.03.09 Azure AD導入環境に対するペネトレーションテストの資格「Certified Az Red Te...
いまさら聞けないパスワードの取り扱い方
そうだったのか！ よくわかる process.nextTick() node.jsのイベントループを理解するshigeki_ohtsu
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
パスワード闇市場：3週間に約3億6,000万件の認証データを販売
PHP foreach $_POST - PHPBuilder Forums