All slide content and descriptions are owned by their creators.
All slide content and descriptions are owned by their creators.
概要 「Javaアプリケーション内から信頼できないかもしれないアドインコードをサンドボックスで実行するための方法」について、簡単なサンプルコードとともに、まとめてみたいと思う。 ※ 信頼できないかもしれない、という意味は後述。*1 セキュリティマネージャとポリシーの有効化 SecurityManagerの有効化 まず、Javaアプリケーションは、何も設定していない場合はセキュリティチェックは全く行わないため、どのような操作でも全て許可されている状態と同じとなる。 セキュリティチェックを有効にするには、 // セキュリティマネージャを有効にする. System.setSecurityManager(new SecurityManager()); とすれば良い。 このようにすると、ファイルの作成などの権限チェックすべき各種タイミングでセキュリティチェックが行われるようになる。 ※ 設定した瞬間
HTML5 は、WHATWG および W3C が HTML4 に代わる次世代の HTML として策定を進めている仕様であり、HTML5 およびその周辺技術の利用により、Web サイト閲覧者 (以下、ユーザ) のブラウザ内でのデータ格納、クライアントとサーバ間での双方向通信、位置情報の取得など、従来の HTML4 よりも柔軟かつ利便性の高い Web サイトの構築が可能となっています。利便性が向上する一方で、それらの新技術が攻撃者に悪用された際にユーザが受ける影響に関して、十分に検証や周知がされているとは言えず、セキュリティ対策がされないまま普及が進むことが危惧されています。 JPCERT/CCでは、HTML5 を利用した安全な Web アプリケーション開発のための技術書やガイドラインのベースとなる体系的な資料の提供を目的として、懸念されるセキュリティ問題を抽出した上で検討を加え、それらの問題
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest(ヘッダおよび、POSTの場合はボディを含む)を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse(ヘッダおよび、HTML)を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
(Last Updated On: 2018年8月20日)問題:まちがった自動ログイン処理の解答です。このブログエントリは最近作られたアプリケーションでは「問題」にしたような実装は行われていないはず、と期待していたのですがあっさり期待を破られたのでブログに書きました。このブログの方が詳しく書いていますけが「Webアプリセキュリティ対策入門」にも正しい自動ログイン処理を書いています。 参考:自動ログイン以外に2要素認証も重要です。「今すぐできる、Webサイトへの2要素認証導入」こちらもどうぞ。HMACを利用した安全なAPIキーの送受信も参考にどうぞ。 間違った自動ログイン処理の問題点 まず間違った自動ログイン処理を実装しているコードの基本的な問題点を一つ一つ順番にリストアップします。 クッキーにランダム文字列以外の値を設定している クッキーにユーザ名が保存されている クッキーにパスワードが保
2013/06/11 コース:元祖こってり 「元祖こってり」記事はネットエージェント旧ブログ[netagent-blog.jp]に掲載されていた記事であり、現在ネットエージェントに在籍していないライターの記事も含みます。 6月9日(日) に放映された「ほこ×たて」の「たて」の裏側について 2013年6月9日に放映されました、フジテレビ「ほこ×たて」に関しまして、反響が大きいようですので撮影の裏側をご紹介いたします。 まず、番組コーナー内の冒頭にご紹介いただきました弊社製品「防人」については、弊社がどのような会社なのかを簡単に紹介するということでお見せしましたが、防人はメールによる標的型攻撃を防ぐための製品ですので、その後の対決には一切使用していません。 実際の対決に際して防御側に求められたのは、サービスパックや修正プログラムの全く当てられていないパソコン上で、脆弱性が確実に存在しているサー
Webサイトのパスワード認証を狙った攻撃が大きな脅威になっています。 Tサイト(プレスリリース) goo(プレスリリース) フレッツ光メンバーズクラブ(プレスリリース) eBook Japan(プレスリリース) My JR-EAST(プレスリリース) これらの事例のうちいくつか(あるいは全て)は、別のサイトで漏洩したIDとパスワードの一覧表を用いた「パスワードリスト攻撃(後述)」であると考えられています。パスワードリスト攻撃を含めて、パスワードを狙った攻撃が成立してしまう原因は、利用者のパスワード管理に問題がある場合が多く、攻撃を受けたWebサイト側には、直接の責任はないケースが多いと考えられます。 しかしながら、 大半の利用者はパスワード管理に興味がない パスワード認証を採用している理由は、コスト上の理由、すなわちサイト側の経済的な事情 インターネットが「とても危険なもの」となるとネット
1. YAPC::ASIA TOKYO 2011 Webアプリでパスワード保護は どこまでやればいいか HASHコンサルティング株式会社 徳丸 浩 twitter id: @ockeghem Copyright © 2011 HASH Consulting Corp. 1 2. 徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを
プログラムのバイナリ自体が改ざんされる可能性を無視して、解析・偽装が困難なライセンスキーを生成/検証する手法というと、やっぱり以下のような公開鍵暗号方式になるんだろうか。 RSAのキーペアを作成しておく。 管理者側は「プログラム固有の情報+ユーザ固有の情報」を秘密鍵で暗号化してライセンスキーとする。 1024ビットの鍵の場合、パディングの88ビットを引いて936ビット=117バイトを固有情報の記述に使用可能。ユーザ名とメールアドレス程度の情報は格納することができる。 この場合、ライセンスキーの長さも1024ビットになる。これをBase64でエンコードすれば172文字のキーになる。Base16なら256文字。 プログラム側には公開鍵を埋め込んでおく。 ユーザが入力したライセンスキーを公開鍵で復号化して検証する。 以下はライセンスキー生成部のサンプル。 import java.math.Big
In some of the feedback I have gotten on the openID Connect spec, the statement is made that Connect is too complicated. That OAuth 2.0 is all you need to do authentication. Many point to Identity Pro… 英語読みたくないという人のために簡単に解説すると… OAuth 2.0 の implicit flow を使って「認証」をしようとすると、とっても大きな穴が開きます。 カット&ペーストアタックが可能だからです。 OAuth 認証?は、図1のような流れになります。 図1 OAuth 認証?の流れ 一見、問題なさそうに見えます。しかし、それはすべてのサイトが「良いサイト」ならばです。 Site_A
Although it is possible to use JAAS within Tomcat as an authentication mechanism (JAASRealm), the flexibility of the JAAS framework is lost once the user is authenticated. This is because the principals are used to denote the concepts of "user" and "role", and are no longer available in the security context in which the webapp is executed. The result of the authentication is available only through
認証・承認を行うプログラム ユーザー認証や権限の制御を行うために標準APIとしてJAAS(Java Authentication and Authorization Service) APIがあります。 JAASには、ユーザーが正当であることを確認する認証と、ユーザーの権限に応じて要求を制御する承認の2つの要素があります。 認証 認証で使用する主要APIは以下です。 javax.security.auth.login.LoginContext javax.security.auth.spi.LoginModule javax.security.auth.callback.CallbackHandler javax.security.atth.callback.Callback 認証のフローは大まかには以下です。 アプリケーションがLoginContextクラスをインスタンス化する Logi
春の伊予国漫遊記。松山・今治と愛媛の魅力を満喫してきました。 法事を兼ねて愛媛観光へ 2024年のGWは、毎年恒例の名古屋帰省ではなく自宅でゆっくり過ごしておりました。というのも、4月に法事のため愛媛・松山に親族大集合というイベントがありまして、そちらをGWの旅行代わりにしたという理由です。法事は日曜日の予定ということ…
いくつか依存JarがあるのでMavenを使うと楽。 <dependency> <groupId>securityfilter</groupId> <artifactId>securityfilter</artifactId> <version>2.0</version> </dependency> web.xmlにフィルタ設定を記述 <filter> <filter-name>securityfilter</filter-name> <filter-class>org.securityfilter.filter.SecurityFilter</filter-class> <init-param> <param-name>config</param-name> <param-value>/WEB-INF/securityfilter-config.xml</param-value> </in
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く