タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

セキュリティに関するsachiko-kameのブックマーク (17)

  • メール暗号化とは?重要性や方式、実施する際の注意点を解説!|ITトレンド

    メールのセキュリティ強度を高め、情報漏えいを防止する「メール暗号化」。しかし、メール暗号化の仕組みが分からず、適切なセキュリティ対策を行えていない企業は多いです。そこで、この記事ではメール暗号化の重要性や仕組みを詳しく解説していきます。 暗号化するときの注意点もあわせて紹介するため、ぜひ参考にしてください。 メール暗号化は文や添付ファイルの内容を、第三者に知られないように加工・処理することです。また、一般的にメール暗号化は文や添付ファイルなどを含めて全てを暗号化することを意味します。 特殊な技術を使えば、メールが送信される通信間で内容の盗聴や改ざんができてしまいます。これにより、被害に遭うケースも少なくありません。そこで、メールの暗号化を実施すれば内容を第三者に傍受されなくなります。 メールの暗号化は鍵をかけることに似ており、受信者側は鍵を使って内容を復元します。鍵を持っていなければ内

    メール暗号化とは?重要性や方式、実施する際の注意点を解説!|ITトレンド
  • IPA ISEC セキュア・プログラミング講座:Webアプリケーション編 第2章 アクセス制限対策:ユーザー認証対策

    個人情報、取引情報、有償コンテンツ等を取り扱うような場合、Webアプリケーションにおいても、リソースへのアクセスを許可されたユーザのみが行えるようにする仕組み、すなわちアクセス制御のメカニズムが必要となる。 ユーザ認証とアクセス認可 コンテンツへのアクセスは、ユーザ認証とアクセス認可の 2段階の機能で構成するのが一般的である。 ユーザ認証 アクセス要求してきた実体(entity)が人であることを確かめる機能 アクセス認可 ユーザ認証の関門を通過した実体に対して、コンピュータのリソースへのアクセスを許可あるいは禁止する機能 Webアプリケーションのユーザ認証においては次のような点を考慮する。 常にユーザIDとパスワードを求める ユーザ認証とは、アクセスを要求するユーザが人であることを確認する仕組みであり、ユーザ固有の識別子である「ユーザID」とユーザのみが知っていると仮定される「パスワー

    sachiko-kame
    sachiko-kame 2021/02/22
    "会員登録 ログイン周り"
  • Twitterのフリート機能に対する権限昇格

    はじめにTwitterはBug Bountyプログラム(脆弱性報奨金制度とも呼ばれる)を実施しており、脆弱性の診断行為を行うことが認められています。 記事は、そのプログラムを通して報告された脆弱性についてを解説したものであり、Twitterが認知していない未修正の脆弱性を公開する事を意図したものではありません。 また、Twitter上で脆弱性を発見した場合はTwitterのBug Bountyプログラムより報告してください。 (This article is written in Japanese. If you’d like to read this article in English, please visit HackerOne report.) TL;DRTwitterが公開したフリート機能が使用しているAPIに脆弱性が存在し、READ権限しか持っていないサードパーティアプリケ

    Twitterのフリート機能に対する権限昇格
    sachiko-kame
    sachiko-kame 2021/01/05
    “TwitterのBug Bounty”
  • Apacheの多重拡張子にご用心

    先日の日記『「10日でおぼえるPHP入門教室 第4版」はセキュリティ面で高評価』では、同書のアップロード機能のセキュリティ面を評価しつつ、「もうひと踏ん張り確認して欲しい内容がある」として、画像XSSの可能性について指摘しました。では、これを直せば完璧かというと、実はそうとも言えないという微妙な問題があります。それは、アップロード先の場所とファイル名の問題です。 ファイルをアップロードするディレクトリ: ドキュメントルート下の /php10/doc/ ファイル名: ブラウザから送信されたファイル名そのまま これらのうちファイル名の拡張子については、gif/jpg/jpeg/pngのみを許すという、いわゆるホワイトリスト検査がされていて、またgetimagesize()関数により、画像ファイルであることの簡易的なチェックをしています。しかし、この状態では、環境によってはアップロードしたファイ

    Apacheの多重拡張子にご用心
    sachiko-kame
    sachiko-kame 2020/08/24
    "画像保存"
  • https://geechs-magazine.com/tag/lifehack/20160822_2

    https://geechs-magazine.com/tag/lifehack/20160822_2
    sachiko-kame
    sachiko-kame 2020/05/26
    “SSL通信 SHA-1、SHA-2”
  • 入退室管理システムならAkerun【オフィス向けスマートロック】

    今あるドアに 貼り付けるだけ。 最短3日〜簡単スピード導入! 工具・工事不要で届いたその日から入退室管理を始められます。

    入退室管理システムならAkerun【オフィス向けスマートロック】
    sachiko-kame
    sachiko-kame 2020/04/22
    "ドア施錠"
  • 【HTML】「target=_blank」は使用NG?aタグの脆弱性が話題に

    こんにちは。 毎度久しぶり みつ です。 さて、つい先ほど おやすみ前のネット徘徊をしていると こんな記事を見つけてしまいました。 target=”_blank”には気をつけよう !?!?普通に使っている。 むしろ自分からディレクターに「これ別窓にしますか?ッ了解です!」 とか当たり前にやってましたよ。 でも、知らなかったものは仕方ない 眠くなってきたから寝ようと思ったのですが、 これからwebの世界に飛び込む方々に 「え?target_blank使ってるの」とドヤ顔をしてもらえるように筆をとりました。 (Qiitaでバズってたので、もうドヤ顔はできません。) 目次 target_blankは使っちゃいけないの? rel=”noopener”って何? まとめ target_blankは使っちゃいけないの? 結論、使ってOKです。 ただ、<a href=”hoge” target=”_bla

    sachiko-kame
    sachiko-kame 2020/03/09
    “フィッシング詐欺対策”
  • https://www.ipa.go.jp/files/000054737.pdf

  • 情報システム等の脆弱性情報の取扱いにおける法律面の調査 報告書改訂版

    情報システム等の脆弱性情報の取扱いに おける法律面の調査 報告書改訂版 2019 年 3 月 i 序 「情報セキュリティ早期警戒パートナーシップ」(以下、「早期警戒パートナーシップ」 という)は、基的な枠組みが構築された後、2004 年 7 月 8 日より運用が開始された。当 該運用は、世界的にみて先駆的なこころみとなり、世界的な脆弱性対応の動きをリードす るものとなっている。 脆弱性情報取扱の法律問題研究会が 2004 年に公表した「情報システム等の脆弱性情報 の取扱いにおける法律面の調査」(以下、「法律面の調査報告書(2004 年版)」という) は、脆弱性をめぐる法律問題を広く論じるとともに、脆弱性情報の取扱いルールの必要性 とその意義を考察するものであった。そのような考察の対象が広範であったこともあり、 その後の早期警戒パートナーシップの運営の際に、生じる問題について法的な観点から

    sachiko-kame
    sachiko-kame 2020/02/13
    "法 どこまで法律に抵触するかのってそう、、"
  • 注意喚起

    2024 2023 2022 2021 2020 その他の年 2019 2018 2017 2016 2015 2014 2013 2012 2011 2010 2009 2008 2007 2006 2005 2004年以前 深刻且つ影響範囲の広い脆弱性などに関する情報を告知するための文書です。 情報システムや制御システムに関わる端末やネットワークの構築・運用管理業務、組織内CSIRT業務、セキュリティ関連業務などに関与する担当者、技術者、研究者等を対象としています。 ※2018年1月分から注意喚起のページ表示デザインが変わりました。 <注意> 以下の各文書で紹介しているソフトウェア、バージョン、URL等は、各文書の発行時点のものであり、変更されている可能性があります。 2019 公開日 注意喚起内容 テキスト (PGP署名付き)

    注意喚起
    sachiko-kame
    sachiko-kame 2020/02/13
    "要チェック"
  • 機密情報が大拡散!? 「パスワード後送します」はなぜ“ダサく”なったのか?

    そもそも、セキュリティ対策としてイケているのか? そもそもこの慣習、肝心の情報セキュリティ対策として効果はいかに? ここで残念なお知らせがあります! 【パスワードは容易に解読されうる】 インターネットには、zipファイルのパスワードを解読するツールが出回っています。それを使うと、高度なハッキング技術や知識がなくとも、パスワードは解読できてしまいます。十分に長いパスワードであれば解読困難ですが、それでも特定の条件がそろうと解読できてしまう場合もあります。 【そもそも盗聴対策にはならない】 パスワードは、いわば“箱の鍵”です。箱にどんなに強固な鍵をかけたとしても、箱体と鍵を同じ手段で送ったら、メールサーバーやネットワーク経路で盗み見ようとしている悪人は両方ともゲットできてしまいますね。盗聴対策効果はゼロです。 【そもそも誤送信対策にはならない】 「万が一、メールをまちがった相手に送ってしまっ

    機密情報が大拡散!? 「パスワード後送します」はなぜ“ダサく”なったのか?
    sachiko-kame
    sachiko-kame 2020/01/02
    "送るZIPに鍵かけて意味あるの?無意味です パスワードは簡単に溶けるしそもそも同じ方法で送ること自体盗み方変わらないのでは?といったもの"
  • 「二段階認証」の誤解を解く。「二要素認証」「多要素認証」と何が違うか – サポート − トラスト・ログイン byGMO【旧SKUID(スクイド)】

    2019年7月の「7pay事件」は記憶に新しいところですが、この事件がクローズアップされた際によく取り上げられた言葉に「二段階認証」という言葉があります。そもそも二段階認証とは何か。「二要素認証」「多要素認証」とは何が違うのか、見ていきたいと思います。 知っていますか?「二段階認証」の多くは間違いです セキュリティ向上のための「二段階認証」と聞いて、一般的に思い浮かべるのは、以下のような流れではないでしょうか。 最初、IDとパスワードを入力し認証を行う (一段階目の認証) 次に、IDとパスワード以外のものを入力して認証を行う (二段階目の認証) 二段階の認証を通過するとログインできる。 通常は、1段階目の「ID・パスワード認証」のみなので、認証が2段階で2回求められるので「1段階より安全」という理解が持たれています。しかし、これは2つの意味で正しくありません。 (1)二段階であること自体に

    sachiko-kame
    sachiko-kame 2020/01/02
    "二段階認証と二要素認証"
  • Build software better, together

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    Build software better, together
    sachiko-kame
    sachiko-kame 2019/02/24
    OWASP日本語
  • OWASP Top Ten | OWASP Foundation

    This website uses cookies to analyze our traffic and only share that information with our analytics partners. Accept The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications. Globally recognized by developers as the first step towards more secure coding. Companies should

    sachiko-kame
    sachiko-kame 2019/02/24
    webセキュリティー(英語)
  • 情報処理推進機構:情報セキュリティ:脆弱性対策:安全なウェブサイトの作り方

    「安全なウェブサイトの作り方」は、IPAが届出(*1)を受けた脆弱性関連情報を基に、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、ウェブサイト開発者や運営者が適切なセキュリティを考慮したウェブサイトを作成するための資料です。 「安全なウェブサイトの作り方」改訂第7版の内容 第1章では、「ウェブアプリケーションのセキュリティ実装」として、SQLインジェクション 、OSコマンド・インジェクション やクロスサイト・スクリプティング 等11種類の脆弱性を取り上げ、それぞれの脆弱性で発生しうる脅威や特に注意が必要なウェブサイトの特徴等を解説し、脆弱性の原因そのものをなくす根的な解決策、攻撃による影響の低減を期待できる対策を示しています。 第2章では、「ウェブサイトの安全性向上のための取り組み」として、ウェブサーバの運用に関する対策やウェブサイトにおけるパスワードの取扱いに関す

    情報処理推進機構:情報セキュリティ:脆弱性対策:安全なウェブサイトの作り方
  • @IT:クロスサイトスクリプティング対策の基本

    最近Webアプリケーションに存在するセキュリティホールが注目を浴びている。その中でも「クロスサイトスクリプティング」と呼ばれる脆弱性が有名であるが、クロスサイトスクリプティング脆弱性について正確に理解している人が依然として少ないと感じる。 稿では、クロスサイトスクリプティングとはどのような脆弱性であるのか、この脆弱性を持ったサイトが攻撃されるとどのような被害が起き得るのか、なぜそのようなセキュリティホールが作り込まれてしまうのか、どのように対策をすればよいのかを解説していく。 ※以下文中では、クロスサイトスクリプティング脆弱性のことを「XSS」と表記する。「Cross Site Scripting」の略であるから「CSS」と表記している記事もあるが、「Cascading Style Sheets」の略も「CSS」となり紛らわしいため、「XSS」と表記する場合が多くなってきている。稿で

    @IT:クロスサイトスクリプティング対策の基本
  • CSRF(クロスサイトリクエストフォージェリ)とは?被害と対策も

    CSRF(Cross-Site Request Forgeries、クロスサイトリクエストフォージェリ)は、Webシステムを悪用したサイバー攻撃の一種です。 CSRFの手口は、ユーザーが悪意のあるURLにアクセスしてしまった場合に、意図しないリクエストを特定のWebサービスに送られてしまうというものです。Webサイトのリンクやメールに記載されたリンクをクリックして、URLのアドレスにアクセスすることで特定のWebサービスへのリクエストが送られてしまいます。 特定のWebサービスへのリクエストは、Webサービスによって内容は変わるものの、Webサービスの設定変更や値の入力、操作の実行などに繋がります。また、WebサービスSNS掲示板の場合には、悪意のあるURLに設定した内容を投稿してしまうことになります。 ユーザーの意図しない情報・リクエストが送信されてしまうためリクエスト強要とも呼ばれ

    CSRF(クロスサイトリクエストフォージェリ)とは?被害と対策も
  • 1