タグ

securityに関するdannのブックマーク (110)

  • AWSアカウント作ったらこれだけはやっとけ!IAMユーザーとAuthyを使ったMFAで2段階認証 - Qiita

    AWSアカウントを安全に運用したいなら最低限これだけはやっとけというTIPSです。 0.AWSのアカウントの種類 AWSアカウントを作ったときには、AWSのrootアカウントしか存在していません。 このままだと「メールアドレス」「パスワード」で「AWSリソースの操作が何でも」できてしまいます。 そこで管理コンソールへのログインはMFA(Multi-Factor Authentication)を利用したうえで、root以外にIAM Userというアカウントを作成し、限定した権限で利用することが強く推奨されています。 rootアカウント:AWSアカウント作成時に作成される何でもできるユーザー IAMユーザー:権限を限定して設定できるユーザー 1.Authyのセットアップ 2段階認証を導入するためにハードウェア型のMFAデバイスか、ソフトウェア型のVirtual MFAが使用可能です。今回はVi

    AWSアカウント作ったらこれだけはやっとけ!IAMユーザーとAuthyを使ったMFAで2段階認証 - Qiita
  • dependency-check – About

    OWASP dependency-check is an open source solution to the OWASP Top 10 2021 entry: A06:2021 – Vulnerable and Outdated Components. Dependency-check can currently be used to scan software to identify the use of known vulnerable components. For a full list of supported languages/technologies please see the File Type Analyzer page). Note that some of the analyzers are experimental and may produce more

  • CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある - co3k.org

    CSRF 脆弱性対策には攻撃者の知り得ない秘密情報をリクエストに対して要求すればよく、そのような用途としてはセッション ID がお手軽でいいよねという時代があったかと思います。 いや、もちろん、 CSRF 対策の文脈だけで言えば今も昔も間違いというわけではありません。セッション ID が秘密情報であるのは Web アプリケーションにおいて当然の前提ですので、 CSRF 対策としてリクエストに求めるべきパラメータとしての条件はたしかに満たしています。 たとえば 『安全なウェブサイトの作り方』 改訂第6版では以下のように解説されています。 6-(i)-a. (中略) その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。 (中略) この秘密情報は、セッション管理に使用しているセッション ID を用いる方法の他、

  • psad - Intrusion Detection with iptables, iptables Log Analysis, iptables Policy Analysis

    psad: Intrusion Detection and Log Analysis with iptables psad is a collection of three lightweight system daemons (two main daemons and one helper daemon) that run on Linux machines and analyze iptables log messages to detect port scans and other suspicious traffic. A typical deployment is to run psad on the iptables firewall where it has the fastest access to log data. Download Documentation Feat

    psad - Intrusion Detection with iptables, iptables Log Analysis, iptables Policy Analysis
  • SECCON2013 slide

    SECCON2013北陸前日勉強会のスライドです http://2013.seccon.jp/2013events.html 元データここ https://gist.github.com/mala/8112696

    SECCON2013 slide
  • 新しい暗号技術

    2. 自己紹介  大学時代  京都大学数理解析研究所では代数幾何 コンピュータとは縁のない世界  暗号にも興味を持つ  mp3エンコーダ「午後のこ~だ」の開発(LGPL2)  就職後  IPAからの依頼で暗号解読プログラムの作成(2004年)  『機械学習の学習』(CCA-BY3) 2012年ジュンク堂のコンピュータ書籍売り上げ3位  http://compbook.g.hatena.ne.jp/compbook/20130110  暗号の高速な実装(2013/8の時点で世界最速) The Realm of the Pairings(SAC2013)  http://sac2013.irmacs.sfu.ca/sched.html 2013/11 2 /58 3. 目次  暗号  mod pの世界  巾乗の計算  離散対数問題  ElGamal暗号 

    新しい暗号技術
  • mod_process_security - Apache上でスレッド単位で権限分離を行うファイルのアクセス制御アーキテクチャ(前半編)

    人間とウェブの未来(旧) 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 ソース 「スレッド単位で権限分離を行うWebサーバ上のアクセス制御アーキテクチャ」として、3月15日16日に開催されたIA/IOT/SITE/ISMS合同研究会で発表してきた。概ね、好評だったように思う。ただ、やらないといけないことはいくつかあるので、そこはこれから大学で適宜やっていこうと思う。 まずは、この論文の概要としては、 大規模Webサーバ上で大多数のユーザー(仮想ホスト)を一つのサーバで処理するようなマルチテナント環境において、ユーザー間のセキュリティを担保するためのアクセス制御を行う技術 である。(これまではsuEXECが使われていた) これは、Webサービスが高度化していく時代において、低価格化がより望まれてきており、以前に増し

    mod_process_security - Apache上でスレッド単位で権限分離を行うファイルのアクセス制御アーキテクチャ(前半編)
  • Java アプリケーション脆弱性事例解説資料

    2014 2013 セキュアコーディングを学ぶための教材として活用していただくことを目的として、Java 言語で書かれたアプリケーションの脆弱性事例に関する解説資料を公開しています。 セキュアな Java アプリケーションの開発を目指すには、すでに知られている脆弱性の具体例を理解し、それを反面教師として同じ失敗を繰り返さないようにすることが重要です。 Java言語によるセキュアなプログラムを開発するためのコーディング規約「Java セキュアコーディングスタンダード CERT/Oracle版」や、Javaセキュアコーディングセミナー資料とともに、資料を自習や勉強会などの参考資料としてご活用ください。 2014 公開日 タイトル PDF PGP 署名

    Java アプリケーション脆弱性事例解説資料
  • パスワード保存とソルトの話

    先日、twitterへのハッキング行為が発見された、という発表がなされました。一部のユーザのデータが漏洩したということです。 この件について個人的に懸念を感じたため、それをこちらに書いておきました。原文では encrypted/salted password と呼ばれていたものが、日語の公式ブログでは「暗号化されたパスワード」となり、これが朝日新聞では「パスワード」と表記されているという問題です。 専門知識があれば、ここにどういう違いがあるかはわかるのですが、そうでなければわからないのも無理はありません。しかし、わからないからといって省略して良いわけでもありません。パスワードと encrypted/salted password は大きく異なります。 ではどう違うのか? この話について、ひと通りの解説をしてみるのも良いのではないかな、と思ったのでしてみます。 「パスワード」は保存されない

  • 徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2012

    2. 日お話しする内容 • 鉄則1: PHP自体の脆弱性対処をしよう • 鉄則2: Ajaxの脆弱性対処をしよう • 鉄則3: 競合条件の脆弱性対処をしよう • 鉄則4: htmlspecialcharsの使い方2012 • 鉄則5: escapashellcmdは使わないこと • 鉄則6: SQLインジェクションの対処 • 鉄則7: クロスサイト・スクリプティングの対処 • 鉄則8: クロスサイト・リクエスト・フォージェリの対処 • 鉄則9: パスワードの保存はソルトつきハッシュ、できればスト レッチングも • 鉄則10: 他にもたくさんある脆弱性の対処 Copyright © 2012 HASH Consulting Corp. 2 3. 徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍

    徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2012
  • security:sslは暗号化のためのものではありません [TenForward]

    <fs 150%><color red>@kfujieda さんによるもっと良い翻訳が登場しました.勉強になります.このページのものよりそちらをご参照ください.</color>→ SSL is not about encryption</fs> <color red>言い訳になりますが,もちろん藤枝さんのおっしゃるような「SSLの主目的は暗号化ではない」というのは理解しています.そこをあえて今回のようなタイトルに訳したのは私なりの考えがあってのことです.ただ,「翻訳」というものが期待されるものからすると不適当だったかも知れません.</color> <color red>自分が通信をしたい相手であることがきちんと確認が取れた相手と暗号化通信を行わないと意味がないと思いますが,「暗号化されてるからいいでしょ」というような事を今まで何度か聞いた事があり,それは違うだろうと思った事があります.この

  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • [デブサミ2012]趣味と実益の脆弱性発見

    1. Finding Vulnerabilities For Fun And Profit 趣味と実益の脆弱性発見 Feb 16 2012 Yosuke HASEGAWA 2. 自己紹介 はせがわようすけ ネットエージェント株式会社 研究開発部 株式会社セキュアスカイ・テクノロジー 技術顧問 Microsoft MVP for Consumer Security Oct 2005 - http://utf-8.jp/ 難読化JavaScript書いてます Developers Summit 2012 NetAgent http://www.netagent.co.jp/ 4. 記号JavaScript JS without alnum $=~[];$={___:++$,$$$$:(![]+"")[$],__$:++$,$_$_:(![]+"")[$],_$_:+ +$,$_$$:

    [デブサミ2012]趣味と実益の脆弱性発見
  • 高木浩光@自宅の日記 - spモードはなぜIPアドレスに頼らざるを得なかったか

    ■ spモードはなぜIPアドレスに頼らざるを得なかったか spモードの事故 NTT docomoのスマホ向け独自サービス「spモード」が、今月20日に大規模な事故を起こして、重大事態となっている。 スマホ向けネット接続が不具合 ドコモ 別人のアドレス表示, MSN産経ニュース, 2011年12月20日 ドコモのspモードで不具合、他人のメールアドレスが設定される恐れ, 日経IT Pro, 2011年12月21日 ドコモの「spモード」でトラブル、関連サービスが一時停止, ケータイ Watch, 2011年12月21日 ドコモ、spモード障害で「ネットワーク基盤高度化対策部」設置, ケータイ Watch, 2011年12月26日 ドコモ 約1万9000人に影響, NHKニュース, 2011年12月27日 ドコモの“メアド置き換え”不具合、影響数や新事象が明らかに, ケータイ Watch,

  • サードパーティCookieの歴史と現状 Part2 Webアプリケーションにおける利用とその問題 - 最速転職研究会

    前回 http://d.hatena.ne.jp/mala/20111125/1322210819 の続きです。 前回のあらすじ ブラウザベンダーはサードパーティCookieをデフォルトでオフにしたかったんだけどお前らがサードパーティCookieに依存したサイト作るし使うからオフに出来なかったんだよ!!!!! といった事情を踏まえた上でWebアプリケーションにおけるサードパーティCookieの利用の歴史について書きます。前提知識の共有が済んだので、ここからはある程度個人的な意見も含まれます。実装面での技術的な内容も含みます。 サードパーティCookieが必要とされてきた歴史 広告のためのトラッキングCookie以外にも、サードパーティCookieに依存したサービスが数多く存在してきた。個人的に把握しているいくつかのサービスについて時系列で述べる。ついでに広告業界の流れについても重要なのを幾

    サードパーティCookieの歴史と現状 Part2 Webアプリケーションにおける利用とその問題 - 最速転職研究会
  • Amon2とJSONとセキュリティ - tokuhirom's blog

    [1]http://d.hatena.ne.jp/ockeghem/20110907/p1[2]http://www.atmarkit.co.jp/fcoding/articles/webapp/05/webapp05a.html[3] http://msdn.microsoft.com/ja-jp/asp.net/ff713315[4] http://labs.cybozu.co.jp/blog/kazuho/archives/2007/01/cross-site_including.phpあたりをよんで、JSON とセキュリティについてかんがえてみた。 ここで、有効とされている対策のうち while(1); を先頭に付与するPOST ですべて処理するといったあたりは、RESTful でないし、BK 感がひどいというか質的ではないのでできるだけやりたくない。 また、Amon2 では互換

  • サードパーティCookieの歴史と現状 Part1 前提知識の共有 - 最速転職研究会

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

    サードパーティCookieの歴史と現状 Part1 前提知識の共有 - 最速転職研究会
  • Java コーディングスタンダード CERT/Oracle 版

    Top へ AA参考情報 References (CERT Oracle Secure Coding Standard for Java のページにとびます) 『Java セキュアコーディング 並行処理編』 Top へ BBGlossary Glossary (CERT Oracle Secure Coding Standard for Java のページにとびます) Top へ XXお問い合わせ ページに関するご質問・お問い合わせは、secure-coding@jpcert.or.jp までメールにてお願いいたします。 Top

    Java コーディングスタンダード CERT/Oracle 版
  • 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アプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを

    Webアプリでパスワード保護はどこまでやればいいか
  • 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(徳丸浩)の日記