Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ゴールデンウィークのはじめ（4月29日）に投稿された以下のツイートですが、5月7日20時において、1,938.8万件の表示ということで、非常に注目されていることが分かります。 我が名はアシタカ！スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた。どうすればよい！ pic.twitter.com/e26L1Bj32Z — スタバでMacを開くエンジニア (@MacopeninSUTABA) April 29, 2023 これに対して、私は以下のようにツイートしましたが、 これ入社試験の問題にしようかな。『
2016-2017年でのNIST SP800-63-3改定を通じて、認証を含むデジタルアイデンティティの世界では様々な議論が湧き起こりました。 そんな本ガイドラインの内容を通じて、デジタルアイデンティティフレームワークを考える上での共通言語、特に「認証方法」について記載したNIST SP800-6…
Merry X(ma)ss (Shanon Advent Calender 2016 - 25日目)
Uncategories Merry X(ma)ss (Shanon Advent Calender 2016 - 25日目) Merry X(ma)SS (Shanon Advent Calender 2016 - 25日目) こんにちは，こんばんは，メリー・クリスマス，開発エンジニャーの t です． 顔認識から始まり，テスト，PM，子育て，開発プロセス，VR, AWS, RoboHon, Golang etc. と多種多様なテーマを技術部他総出演で展開してきた Shanon Advent Calender 2016 も無事最終日となりました． 最終日，25日は Merry XmaS と掛けて 2016年に出会った XSS の話で締めたいと思います． はじめに ひとくちに XSS といっても色々有りますが，主に DOM based XSS と呼ばれるクライアントサイド（ブラウザ）で起こる
DeNAの奥さんと、はるぷさんがJSON SQL Injectionについて公表されています。 The JSON SQL Injection Vulnerability 不正なJSONデータによるSQL Injectionへの対策について (Json.pm+SQLクエリビルダー) 上記の記事は、主にPerlスクリプトがJSONデータを受け取るシナリオで説明されています。もちろん、この組み合わせに限定したはなしではないわけで、それではPHPではどうだろうと思い調べてみました。 JSON SQL Injectionとは 以下、はるぷさんの「不正なJSONデータによる…」にしたがってJSON SQL Injectionについて説明します。 Perl向けのSQLジェネレータの一つであるSQL::Makerにおいて、以下のスクリプトを想定します。 my ($sql, @bind) = $builde
Kazuho's Weblog: The JSON SQL Injection Vulnerability について。元記事をはっちゃめっちゃに要約すると SQL::Maker にユーザから受けとったデコード済み JSON をそのまま突っ込むと SQL インジェクションになる場合がある SQL::Maker 側でそういったことが起こらないように strict オプションをつけたから、できればそっち使え 別に SQL::Maker に限らないから気をつけろ という話っぽい。本来であればユーザ入力をタイプチェックをすべきだけど、クエリビルダレベルでも、脆弱性にならないようにもうちょっと考慮してもいいよねという趣旨かな… strict モードは非互換なので、既存のコードが動かなくなる可能性があるようです。 Teng での対応 Teng を使っているとデフォルトで SQL::Maker がクエリビ
► 2024 (1) ► 4月 (1) ► 2023 (2) ► 4月 (1) ► 3月 (1) ► 2022 (6) ► 12月 (1) ► 9月 (1) ► 7月 (1) ► 5月 (1) ► 3月 (1) ► 1月 (1) ► 2021 (1) ► 12月 (1) ► 2020 (4) ► 12月 (1) ► 11月 (1) ► 5月 (1) ► 3月 (1) ► 2019 (11) ► 12月 (2) ► 7月 (2) ► 5月 (2) ► 4月 (2) ► 3月 (1) ► 2月 (1) ► 1月 (1) ► 2018 (15) ► 12月 (3) ► 11月 (6) ► 10月 (2) ► 9月 (2) ► 3月 (1) ► 1月 (1) ► 2017 (17) ► 12月 (2) ► 11月 (1) ► 10月 (1) ► 9月 (2) ► 8月 (2) ► 7月 (1) ►
高橋: こんにちは、高橋です。今日は徳丸さんをお招きして、JALの不正ログイン事件についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: 徳丸です。よろしくお願いします。 高橋: まず、事件の概要を説明します。日本航空のホームページに不正アクセスがあり、JALマイレージバンク（JMB）のマイルが、Amazonのギフト券に勝手に交換される被害がありました。日本航空の発表では、1月31日から2月2日にかけて、身に覚えがないマイル交換がされているという問い合わせが複数ありました。調査の結果、40人の利用者のマイルがアマゾンのギフト券、数百万円相当と交換されていたというものです。 徳丸: ここで問題となるのは、パスワードは数字6桁ということなんですよね。 高橋: やはりそこですか。パスワードが数字6桁だとどのような攻撃ができるのでしょうか? ブルートフォース攻撃 徳丸: まず、ブルートフ
今まで2回にわたって、SQL識別子のエスケープの問題を取り上げました。 間違いだらけのSQL識別子エスケープ SQL識別子エスケープのバグの事例 3回目となる本稿では、SQL識別子の取り扱いに関する問題を整理して､一般的な原則を導きたいと思います。 SQL文が動的に変化する場合のSQLインジェクション対策 「間違いだらけの…」で示したように、識別子エスケープが必要な局面でそれが洩れていると脆弱性の要因になることがありますが、それは外部から指定したデータにより、SQL文の構造が変化してしまい、アプリケーションの要件にないSQL呼び出しがなされてしまうからでした。 しかし、「間違いだらけ…」の後半で示したように、識別子のエスケープだけではセキュリティ問題を防ぐことはできず、情報漏洩を招いてしまいました。外部から任意のSQL識別子を指定できることが問題という結論でした。 上記のように、アプリケー
これから3回連載の予定で、SQL識別子のエスケープの問題について記事を書きます。SQL識別子のエスケープについてはあまり解説記事などがなく、エンジニア間で十分な合意がないような気がしますので、これらの記事が議論のきっかけになれば幸いです。 3回の予定は以下のとおりです。 間違いだらけのSQL識別子エスケープ(本稿) SQL識別子エスケープのバグの事例 SQL識別子は結局どうすればよいか ということで、まずはSQL識別子のエスケープの失敗例について説明します。この失敗例はあくまで説明のために作ったもので、実際のものではありません。また、想定が「ありえない」と思われるかもしれませんが、意図的なものですのでご容赦いただければと思います。また、「間違いだらけの」というタイトルは、今回の題材が間違いだらけという意味であり、巷のSQL呼び出しがそうであるという意味ではありません。本稿に登場する人物と団
総務省が12月18日に『リスト型アカウントハッキングによる不正ログインへの対応方策について（サイト管理者などインターネットサービス提供事業者向け対策集）』という資料を公開した。流出したユーザーID/パスワードのリストを使って複数のサイトに対しログインを試みるというタイプの攻撃が最近増えていることから、これに対する対策方法を紹介するというものだが、ここで対策の1つに「パスワードの有効期間設定」が紹介されている点が議論になっている（セキュリティ研究者高木浩光氏のTweet、セキュリティ研究者徳丸浩氏のTweet、Togetterまとめ）。 パスワードの定期的変更がセキュリティの向上にどれだけ意味があるのかについては、たびたび徳丸浩氏がまとめている（パスワードの定期的変更に関する徳丸の意見まとめ、パスワードの定期的変更について徳丸さんに聞いてみた(1)、パスワードの定期的変更について徳丸さんに聞
前回は、リスト型攻撃に対抗すべく皆さんが行なえる対策について提案させていただきました。そこでも解説したとおり、根本的な問題に「パスワードの使い回し」や、「安易なパスワードの設定」があるわけですが、筆者は、世の中で一般に適用されている”あるルール”がそうした状況を誘発しているのではないかと考えています。今回はそのルールを紹介しますので、皆さんには、ルールの是非について考えていただきましょう。 著者プロフィール 辻 伸弘氏(Tsuji Nobuhiro) - ソフトバンク・テクノロジー株式会社 セキュリティエンジニアとして、主にペネトレーション検査などに従事している。民間企業、官公庁問わず多くの検査実績を持つ。 また、アノニマスの一面からみ見えるようなハクティビズムやセキュリティ事故などによる情勢の調査分析なども行っている。趣味として、自宅でのハニーポット運用、IDSによる監視などを行う。 T
高橋: こんにちは、高橋です。前回に引き続き、徳丸さんをお招きして、パスワードの定期的変更問題についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: はい。よろしくお願いします。 高橋: 前回は、「オンライン攻撃に対する予防としてパスワードの定期的変更は意味がない」という結論でしたが、今回は、事後の被害軽減策として、パスワードの定期的変更に意味があるか、というテーマですね。 徳丸: はい。その事後の話ですが、2つの話題があります。まず、前回の続きで、パスワードハッシュ値が漏洩してオフライン攻撃で解読されるまでの時間稼ぎとして、パスワードの定期的変更に意味があるか、次に、パスワードそのものが漏れている場合の緩和策として、定期的変更に意味があるかです。 高橋: それでは、まずハッシュ値が漏洩しているケースについてお願いします。 徳丸: はい。まず、前提として「パスワードを3ヶ月毎に変
例えば職場でユーザーが席を外している間に他人が操作するなど、PCに物理的にアクセスできれば誰でもChromeに保存されたパスワードをのぞき見ることができてしまう。 米GoogleのWebブラウザ「Chrome」に保存されたパスワードは、設定ページを通じて誰でも簡単に平文で見ることができてしまう――。ソフトウェア開発者が自身のブログでそんな実態を報告し、Googleのパスワードセキュリティ対策の甘さを指摘している。 ソフトウェア開発者のエリオット・ケンバー氏は8月6日、「Chromeのあり得ないパスワードセキュリティ戦略」というタイトルのブログでこの実態を紹介した。 同氏はWebブラウザをAppleのSafariからChromeに切り替えて使っている過程で、Chromeの設定ページから保存したパスワードの一覧を表示すると、この画面にパスワードの「表示」ボタンが現れることを発見した。このボタン
高橋: こんにちは、高橋です。今日は徳丸さんをお招きして、パスワードの定期的変更問題についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: 徳丸です。よろしくお願いします。 高橋: まず、お伺いしたいことですが、パスワードを定期的に変更すべしという根拠には、どのようなものがあるのでしょうか? 徳丸: 大きく分けて2つの理由が挙げられていると思います。一つは、パスワードを定期的に変更すると、パスワードを破って侵入する攻撃の予防になるというもの、すなわち事前の予防策です。もう一つは、パスワードが漏洩した際に、被害を軽減できるというもので、事後の緩和策ということですね。 高橋: もう少し詳しくお願いします。 徳丸: まず、「事前」の方ですが、オンライン攻撃とオフライン攻撃があります。 高橋: オンライン攻撃とはどのようなものでしょうか? 徳丸: オンライン攻撃は、ネット経由でパスワード
インターネット上でメールを共有できる米グーグルの無料サービス「グーグルグループ」で、個人情報や中央官庁の内部情報など少なくとも６０００件以上が、誰でも閲覧できる状態になっていることが分かった。 確認できただけで４省庁の職員が業務に関するメールを公開しており、このうち環境省の幹部らは、今年１月に合意された国際条約の交渉過程を流出させていた。他国との会談内容も明かしており、同省は「セキュリティー意識が甘かった」としている。 グーグルグループは、登録者の間で同時にメールを配信できるサービス。ただ、初期設定のままだと閲覧制限がかからないため、気づかないまま情報を誰でも見られる状態にしているケースが多いとみられる。 読売新聞が調べたところ、全国の七つの医療機関や介護施設のメールで３００人以上の病状が掲載されたカルテなどが公開状態になっていた。このほか、高校生の健康診断や中学生の家庭環境、政党の支持者
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Blogger
