タグ

securityに関するnobeansのブックマーク (45)

  • Spring Day 2016 - Web API アクセス制御の最適解

    マイクロサービスアーキテクチャが話題を集め、コンポーネントのWeb API化が更なる急加速を見せる昨今。 とは言え「誰でも自由に叩いて良い」Web APIなんてのは事実上無く、ほぼ全てのケースで何かしらのアクセス制御が必要になります。 - Spring Security もサポートする昔ながらの「Basic認証」。古い、ということは、悪いソリューションなのか? - 最近のAPIのアクセス制御と言えば「OAuth 2.0」がトレンディ? Spring Security OAuth もあるし! - 一方でAWSは「APIキー方式」を採用。なぜAWSはOAuth2ではないのか? - Spring Security はまだ公式にサポートしていない「OpenID Connect」とは一体…? Webにおけるアクセス制御の歴史を振り返りつつ、様々なAPIの立ち位置と共に、その最適解を探っていきたいと思

    Spring Day 2016 - Web API アクセス制御の最適解
  • CMS四天王のバリデーション状況を調査したところ意外な結果になった

    バリデーションでSQLインジェクション攻撃をブロックしないCMSが多い ログインIDにおける典型的なSQLインジェクション攻撃として、'OR 1=1# をバリデーションがブロックするかどうかを確認しました。ログインIDとして許容される文字を見る限り、WordPress、Joomla、Drupalはブロックしそうですが、結果は下記の通りです。 WordPress: ブロックしない Joomla: ブロックする Drupal: ブロックしない MovableType: ブロックしない ということで、意外なことに、バリデーションでSQLインジェクション攻撃を止めるのはJoomlaのみという結果でした。 ログインIDにヌルバイトや改行が使えるCMSがある テストをしていてもっともびっくりしたことの一つがこれです。JoomlaとMovableTypeはヌルバイトや改行など制御文字がログインIDとして

  • 知っておきたい7つのID連携実装パターン

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、ID連携担当のくら(@kura_lab)です。 みなさんはYahoo! JAPANのWeb APIや認証、エンドユーザーの属性取得APIを実装したことがありますか。これらを利用するためにはYahoo! ID連携を用いてアクセストークンの取得やログインの実装が必要になります。単にアクセストークンの取得、ログインの実装といってもWebアプリ、ネイティブアプリにおいていろいろなパターンがあります。 SDKを用いる場合ほとんど意識せずに実装もできますが、提供するサービスのUXやシステムの環境に合わせてより最適な実装をするためには、それぞれの特徴を理解し適切なパターンを選択する必要があります。 Yahoo! ID連携はOAuth

    知っておきたい7つのID連携実装パターン
  • HashiCorp社が出したVaultとはどういうものなのか - 理系学生日記

    HashiCorp 社から、新たなソフトウェアである Vault by HashiCorp がリリースされました。 - HashiCorp Blog: Vault この Vault について、Getting Started を一通り実施した後に Docs の一部を確認してみたので、簡単にその内容をまとめてみます。 Vault とは何なのか Vault を一言で言うと、機密情報(Secret) を管理するツールです。 これだけ IT が広がっている現在、機密情報の範囲も広がり続けており、データベースにアクセスするためのユーザ/パスワードや、連携するシステムの API キー等、多岐に渡ります。こういった情報、おまえのところのシステムではどう管理してた?XML に生で書いてる、あるよねそういうの。jdbc.properties に直書き、うんうんわかるわかる。ちょっとがんばったら crypt で

    HashiCorp社が出したVaultとはどういうものなのか - 理系学生日記
  • SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか

    3. Drupalとは Drupal(ドルーパル、発音: /ˈdruːpəl/)は、プログラム言語PHPで記述され たフリーでオープンソースのモジュラー式フレームワークであり、コンテ ンツ管理システム (CMS) である。昨今の多くのCMSと同様に、Drupalはシ ステム管理者にコンテンツの作成と整理、提示方法のカスタマイズ、管理 作業の自動化、サイトへの訪問者や寄稿者の管理を可能にする。 その性能がコンテンツ管理から、幅広いサービスや商取引を可能にするに まで及ぶことから、Drupalは時々「ウェブアプリケーションフレームワー ク」であると評される。Drupalは洗練されたプログラミング・インター フェースを提供するものの、基的なウェブサイトの設置と管理はプログ ラミングなしに成し遂げることができる。Drupalは一般に、最も優れた Web 2.0フレームワークの一つであると考えられ

    SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
  • Linuxに深刻なセキュリティホール「GHOST」、今すぐパッチが必要

    Steven J. Vaughan-Nichols (Special to ZDNET.com) 翻訳校正: 編集部 2015-01-28 10:04 クラウドセキュリティ企業Qualysの研究者が、Linux GNU Cライブラリ(glibc)に深刻なセキュリティホールである「GHOST」(CVE-2015-0235)を発見した。この脆弱性を利用すると、ハッカーはIDやパスワードを知らなくてもシステムをリモートから乗っ取ることができる。 Qualysはただちにこのセキュリティホールについて主なLinuxの配布元に警告を送り、多くの配布元がすでにパッチを公開している。 このセキュリティホールは、glibc-2.2(2000年11月10日にリリース)を使用してビルドされたすべてのLinuxシステムに存在する。Qualysによれば、このバグは実際には、2013年5月21日にリリースされた、gl

    Linuxに深刻なセキュリティホール「GHOST」、今すぐパッチが必要
  • SQLインジェクション対策もれの責任を開発会社に問う判決

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

  • 漏洩が問題なのではない、名寄せが問題なのである - 第3回プライバシーフリークカフェ(前編) (1/7):テクノロジーでビジネスを加速するための実践Webメディア EnterpriseZine (EZ)

    ベネッセ事件の功 ―名簿屋問題を考える 山 はい、ということで第3回プライバシーフリークカフェ開催いたします。よろしくお願いします。今回も、この3人、新潟大学の鈴木先生と、技術者の高木浩光先生、そして私、山一郎でお送りしたいと思います。 さて、今月先月もいろんなことがありました。その中でも一番冴えたものは、ベネッセ事件がだいぶ続報が報じられて状況がわかるようになってきたかなあ、と。 高木 ちょうど前回、第2回の次の週に報じられましたか、ベネッセ事件は。 山 はい。突然、ベネッセ大爆発という非常に素敵な話が出ましたけども、実際、事件の概要そのものはもうかなり報じられてきています。 高木 なんか今日も、ドコモの記者会見がさっき4時からあったそうで… 山 ええ。法人のデータが、1,100人分くらい出ましたっていう話で終わるのかどうかっていうのが非常に微妙なところかと思うんですけれども、出

    漏洩が問題なのではない、名寄せが問題なのである - 第3回プライバシーフリークカフェ(前編) (1/7):テクノロジーでビジネスを加速するための実践Webメディア EnterpriseZine (EZ)
  • Cisco製品にデフォルトのSSH鍵、特権アクセスされる恐れ

    「Ciscoは全てのシステムに同じSSH鍵を使うという過ちを犯し、その秘密鍵を顧客のシステム上に残しておいた」とSANSは解説している。 米Cisco Systemsは7月2日(現地時間)、「Unified Communications Domain Manager」(Unified CDM)の脆弱性に関する情報を公開した。システムに特権アクセスできるデフォルトのSSH鍵が存在する脆弱性など、3件の脆弱性について解説している。 同社のセキュリティ情報によると、Unified CDMにはサポート担当者へのアクセス用にデフォルトのSSH鍵が存在し、この秘密鍵がシステム上にセキュアでない方法で保存されていることが分かった。攻撃者がこの鍵を入手でき、サポートアカウント経由でシステムにroot権限でアクセスできてしまう状態だという。 この脆弱性について米セキュリティ機関のSANS Internet

    Cisco製品にデフォルトのSSH鍵、特権アクセスされる恐れ
    nobeans
    nobeans 2014/07/03
    これはやばい
  • The Heartbleed Hit List: The Passwords You Need to Change Right Now

    It's time to update your passwords to various sites affected by the Heartbleed bug. Credit: Mashable composite. iStockphoto, SoberP An encryption flaw called the Heartbleed bug is already being dubbed one of the biggest security threats the Internet has ever seen. The bug has affected many popular websites and services -- ones you might use every day, like Gmail and Facebook -- and could have quie

    The Heartbleed Hit List: The Passwords You Need to Change Right Now
  • PHPのイタい入門書を読んでAjaxのXSSについて検討した(3)~JSON等の想定外読み出しによる攻撃~ - ockeghem(徳丸浩)の日記

    昨日の日記の続きで、Ajaxに固有なセキュリティ問題について検討します。今回はJSON等の想定外読み出しによる攻撃です。これら攻撃手法は来ブラウザ側で対応すべきもので、やむを得ずWebアプリケーション側で対応する上で、まだ定番となる対策がないように思えます。このため、複数の候補を示することで議論のきっかけにしたいと思います。 まず、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeから、Ajaxを利用したアプリケーションの概念図を引用します(同書P20の図1-23)。 前回、前々回は、(5)のHTTPレスポンスの前後で、JSON等のデータ作成(エンコード)に起因するevalインジェクションや、(5)のレスポンスを受け取った後のHTMLレンダリングの際のXSSについて説明しました。 しかし、問題はこれだけではありません。正常

    PHPのイタい入門書を読んでAjaxのXSSについて検討した(3)~JSON等の想定外読み出しによる攻撃~ - ockeghem(徳丸浩)の日記
    nobeans
    nobeans 2013/12/06
    GrailsのAjaxなメソッドではrequest.isXhr()チェックしてfalseなら403返す
  • HDIV 2.0:セキュリティフレームワークがSpring MVCとJSTLを統合

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    HDIV 2.0:セキュリティフレームワークがSpring MVCとJSTLを統合
  • もう入力値検証はセキュリティ対策として *あてにしない* ようにしよう

    スタックオーバーフロー対策をする場合、関数の入口でチェックすれば大抵対策可能なんだけど、それだと対策漏れの可能性があるから、例えば、strcpyの代わりにstrncpyあるいはもっと高機能な文字列関数を使うことが当然になってきました。 これは、入口でのチェックだと漏れやすいから、脆弱性が発生するその箇所で対策するという考え方にシフトしているのだと私は考えます。 Webアプリケーションの場合も同様で、XSSやSQLインジェクションの対策は、脆弱性の発生する箇所、すなわち、HTMLの生成とか、SQLの呼び出しの時点で行います。いや、これらは「セキュリティ対策」ではなく、全ての文字を扱うために必要なエスケープ処理に過ぎないので、例がよくないですね。例えば、パストラバーサル脆弱性対処のためのファイル名の確認は、ファイルをオープンする直前(ファイル名を使う直前)に行うべきだ、という考え方です。 スタ

  • 「Java 7 Update 11でも脆弱性は残っているから引き続きJava無効化を」という話について

    Java SE 7 Update 11 でもバグが修正されていない」という専門家の意見が書いてあるロイター通信の記事(Oracle updates Java, security expert says it still has bugs)をTwitterで紹介しましたが、「やはり修正されていない」「修正されたのは2つの脆弱性の内の一つだけ」というニュース記事が複数出てきました。 これらのニュース記事には、「Java 7 Update 11でも脆弱性は残っているから、Java(Java appletを起動するためのブラウザ上のJavaプラグイン)をひきつづき無効化せよ」という内容のCERTの意見が掲載されています(無効化手順はこちら)。 しかし、日語の記事が曖昧で、少し情報源のページを読んでみると、単に「片方が修正されていないから危険」というわけではない、ちょっとややこしい話のようだった

    「Java 7 Update 11でも脆弱性は残っているから引き続きJava無効化を」という話について
  • OAuthの認証にWebViewを使うのはやめよう

    AndroidからTwitterへアクセスするためのライブラリとして,Twitter4Jが有名です. これを使ってみようと,「Android Twitter4J」と検索すると 認証にWebViewを使った例がたくさん出てきます. ・・・いや,ちょっとまて. それはちょっとまずいだろう. そういうわけでもうちょっと賢い方法を探してみました. 何がまずいのさ 「Android Twitter4J」と検索すると,上位にこんなページが出てきます. Twitter4jを使ってOAuth認証をアプリ内で行う方法 Twitter4j-2.2.xを使ったOAuth認証のコーディング例 twitter4jでツイートする Android+Twitter4JでOAuthするためのソースコード 上のサイトでは次の様は方法をとっています. アプリ内にWebViewを貼り付け WebViewでTwitterの認証画面

  • hostsファイルにループバックアドレスを指定することは危険か?

    Androidの広告よけにhostsファイルを書き換えるAdAwayというアプリ(ルート化必要)が紹介されています。それがきっかけとなり、hostsファイルを書き換えることの危険性、とくに他人が作ったhostsファイルをそのまま自端末に適用してしまうリスクがtwitterで話題になりました。 これはまったく正しいのですが、なかのきえた氏から、以下のようにlocalhostIPアドレスを記述することも問題と指摘がありました。 @shigecchi2007 @ks_desire localhost系を書くこともヤバイのです。WindowsでローカルのIISが回り込まれたりWinNTの頃から既知の問題なんです。やるならFirewall機能で適切にブロックする事が必要です。 9月 23, 2012これに対して、ko-zuさんから、ループバックやLAN内ホストでの脆弱性対策についてというブログ記事

    hostsファイルにループバックアドレスを指定することは危険か?
  • サードパーティCookieの歴史と現状 Part1 前提知識の共有 - 最速転職研究会

    Web開発者のためのサードパーティCookieやらトラッキングやらの問題点について三回ぐらいに分けて書きます。 この文章は個人的に書いていますので、おい、お前のところのサービスがサードパーティCookieに依存してるじゃねーかというツッコミがあるかもしれないが、そういうことを気にしているといつまで経っても公開できないという問題が出てしまうので、そんなことはお構いなしに書く。ちなみに例外なく自社サービスに対してもサードパーティCookieに依存するな死ねと言っている。これはWebプログラマー観点で、自分がサービス開発に関わる上で知っておかねばならないだろう知識として十数年間だらだらとWebを見ていて自然に知っていたものと、あるいは興味を持って率先して調べたものが含まれている。ググッて直ぐに分かる程度の用語の定義的なことは書かない。あくまでWebサイト制作者側からの観点なので、ブラウザ開発関係

    サードパーティCookieの歴史と現状 Part1 前提知識の共有 - 最速転職研究会
  • 高木浩光@自宅の日記 - Wi-FiのMACアドレスはもはや住所と考えるしかない

    Wi-FiMACアドレスはもはや住所と考えるしかない 目次 まえがき これまでの経緯 2つのMACアドレスで自宅の場所を特定される場合 SSIDに「_nomap」でオプトアウト? PlaceEngineはどうなった? まえがき 先週、以下の件が話題になった。 Greater choice for wireless access point owners, Official Google Blog, 2011年11月14日 Removing your Wi-Fi network from Google's map, CNET News, 2011年11月14日 グーグルWi-Fiネットワークの位置情報収集で対応策を公開, CNET Japan, 2011年11月16日 Google's WiFi Opt-Out Process Makes Users Navigate Technic

  • Ruby製Webアプリでの書式チェック用正規表現 - 岩本隆史の日記帳(アーカイブ)

    制御文字は不許可にすべき 前回の日記で「単なる書式チェック(文字種や長さなどのチェック)なので、アプリの要件にしたがって粛々と行えばよい」と書いた「(c)パラメータ文字列の妥当性検証」であるが、実は考えるべきことがそれなりにある。アプリの要件として、各パラメータの「許容文字種」と「許容文字数」を決める必要があるのだ。 このうち許容文字数については話が簡単である。最短および最長の許容文字数を決め、入力値がそれを外れていたらエラーにすればよいだけだ。 問題は許容文字種である。たとえば電話番号の入力を想定したパラメータ文字列であれば「数字またはハイフン」が許容文字種となるだろう。では住所欄や感想欄はどうか。あらゆる文字を受け入れてよいのだろうか。 もちろんアプリによってはあらゆる文字を受け入れなければならない場合もあるだろう。しかし「第11回■制御文字や不正な文字エンコーディングによるぜい弱性を

    Ruby製Webアプリでの書式チェック用正規表現 - 岩本隆史の日記帳(アーカイブ)
  • http://www.machu.jp/posts/20110722/p01/

    http://www.machu.jp/posts/20110722/p01/