IDやパスワードなどのユーザアカウントを一元管理するシステムを手がけるOktaが、「ユーザー名が52文字以上だとパスワードによる認証を回避できる脆弱(ぜいじゃく)性」が2024年7月23日から約3カ月間にわたって存在していたと発表しました。 Okta AD/LDAP Delegated Authentication - Username Above 52 Characters Security Advisory https://trust.okta.com/security-advisories/okta-ad-ldap-delegated-authentication-username/ Oktaは2024年11月1日に、同社の委任認証システムである「Okta AD/LDAP DelAuth」に、正しいパスワードを入力しなくてもアカウントにログインできる脆弱性があったと報告しました。 O
個人的に「Webサービスの公開前チェックリスト」を作っていたのですが、けっこう育ってきたので公開します。このリストは、過去に自分がミスしたときや、情報収集する中で「明日は我が身…」と思ったときなどに個人的にメモしてきたものをまとめた内容になります。 セキュリティ 認証に関わるCookieの属性 HttpOnly属性が設定されていること XSSの緩和策 SameSite属性がLaxもしくはStrictになっていること 主にCSRF対策のため。Laxの場合、GETリクエストで更新処理を行っているエンドポイントがないか合わせて確認 Secure属性が設定されていること HTTPS通信でのみCookieが送られるように Domain属性が適切に設定されていること サブドメインにもCookieが送られる設定の場合、他のサブドメインのサイトに脆弱性があるとそこからインシデントに繋がるリスクを理解してお
4. 安全にテクノロジーを活用する Androidで言えばActivityやSQLiteなど、テクノロジーごとにセキュリティ観点の癖というものがある。そうしたセキュリティの癖を知らずに設計、コーディングしていると思わぬ脆弱性をつくりこんでしまうことがある。この章では開発者がAndroidのテクノロジーを活用するシーンを想定した記事を扱う。 4.1. Activityを作る・利用する 4.1.1. サンプルコード Activityがどのように利用されるかによって、Activityが抱えるリスクや適切な防御手段が異なる。ここでは、Activityがどのように利用されるかという観点で、Activityを4つのタイプに分類した。次の判定フローによって作成するActivityがどのタイプであるかを判断できる。なお、どのような相手を利用するかによって適切な防御手段が決まるため、Activityの
図1: 脆弱なパスワードを入力した場合のエラー画面 こんにちは、pixiv開発支援チームのmipsparcです。 パスワード、もしかして使いまわしていますか? 複数のサービスで同じパスワードを利用していると、「パスワードリスト型攻撃」によって不正アクセスの被害を受けてしまうかもしれません。 パスワードリスト型攻撃の被害にあわないためには、ブラウザやパスワード管理ツールで自動生成された安全なパスワードを利用するのが好ましいです。 しかし、実際には多くの人が「使いまわしたパスワード」や「簡単なパスワード」(以下、脆弱なパスワード)を利用していますし、啓蒙活動にも限界があります。 pixivではサイバー攻撃への対策を複数とっていますが、根本的な対策のひとつとして、脆弱なパスワードを新しく設定できないようにしました。 脆弱なパスワードの判定方法 脆弱なパスワードの利用はどのように防ぐことができるで
United States Computer Emergency Readiness Team (US-CERT)は2019年10月30日(米国時間)、「MS-ISAC Releases EOS Software Report List｜CISA」において、米国多州間情報共有・分析センター（MS-ISAC: Multi-State Information Sharing and Analysis Center）が2019年および2020年にサポートが終了するソフトウェアの一覧を公開したと伝えた。 公開された一覧は次のページからダウンロードできる。 End-of-Support Software Report List 一覧には、アドビシステムズ、アトラシアン、チェック・ポイント・ソフトウェア・テクノロジーズ、シスコシステムズ、IBM、オラクル、マイクロソフト、トレンドマイクロ、ヴイエムウェ
毎日のように企業や組織を狙ったサイバー攻撃が繰り返され、その方法も次々と新しくなっています。皆さんの中にはひょっとして、小さな企業を十分守るだけのセキュリティの知識を身に付けるには「ある程度お金がかかるはず」と思っている方もいるのではないでしょうか？ 実は、そんなことはありません！ 内閣サイバーセキュリティセンター（NISC）は2019年4月19日、新たに「小さな中小企業とNPO向け情報セキュリティハンドブック 初版（Ver.1.00）」を公開しました。その内容は、セキュリティ本を上梓している筆者が「ぐぬぬ」とうなったほどです。これは、素晴らしい！ 「どうしてこの人は、他人の本をそこまで推すの……？」と面食らった読者もいるかもしれません。この本を読んでほしいと私が考える根拠を、これから詳しく説明していきましょう。 NISCはこれまでも、個人向けに黄色い表紙の「インターネットの安全・安心ハン
情報推進機構「安全なWebサイトのつくりかた」を読んだけど 情報量が多すぎて頭がフリーズしたので、現時点で最低限理解できる内容までを記録しておきます。 誰にでもわかるというより、僕にでもわかる文章で書いていますのでご了承ください。 Webアプリケーションのセキュリティ実装 例として、１１種類のセキュリティ脆弱性が挙げられています。 「何がまずいのか？」「どんなアプリで注意が必要なのか？」を 噛み砕いてからまとめていきます。 SQLインジェクション Part1（本記事） https://qiita.com/E-46/items/93199f38bdacd6b6076a OS コマンド・インジェクション Part2 https://qiita.com/E-46/items/aa43b6a01de8ab205591 1. SQLインジェクション どんな脆弱性なのか インジェクションとは「注入、投
必須: 基本的に対応が必要。何らかの要因で対応できない場合は関係者への同意をとる。 できれば：状況的に困難でなければなるべく対応する。 基本対応なし：特別な要件がなければ対応しない。 直近修正履歴(2018/11/21) [OS共通] ログ出力の対策にproguardによる方法を追記 [iOS] 通信データのキャッシュの対策に一部問題があったため修正 [OS共通] 通信の暗号化 対応要否：必須 リスクの詳細 HTTPで通信を行うと通信データが平文でネットワークに流れるため、情報漏洩の危険性がある。 対策 通信を行う場合はHTTPS(SSL/TLS)通信を利用する [OS共通] SSL証明書のチェック 対応要否：必須 リスクの詳細 通信やWebViewで行われるSSL証明書の正当性検証を無効化すると、ネットワーク管理者などにより通信経路上のデータ改竄、傍受が可能になる。 対策 試験環境で証明
5月18日、ヤフーが「Yahoo! Japan IDのパスワードを無効化する機能」を発表した。所定のURLで手続きをすると、以降、ヤフーサイトへのログイン、ヤフースマートログイン対応のサービス利用について、パスワードの代わりに登録した携帯番号のSMSで送られてくるワンタイムパスワードを利用するようになる。煩わしいパスワード管理から解放され利便性は高そうだが、セキュリティはどうなのだろうか。 パスワードの限界、追い打ちをかけるリスト型攻撃 パスワードは、長年その欠点とわずらわしさを指摘されながら、総合的に管理しやすく、システムへの実装もしやすいのも事実で、パスワードに代わる決定打もないため、必要悪のように使い続けられている。生活や業務のネット依存が拡大し、必要なパスワードの数は人間の管理能力を簡単に超えてきている。 にもかかわらず、サービス側は使いまわしや覚えやすいフレーズの利用を禁止、制限
EUの個人情報保護に関する新しい法律(General Data Protection Regulation)が2018年5月25日から施行される。EUの居住者に対してサービスを提供していて個人情報を取り扱っている業者は、たとえ個人であろうとも遵守義務が課せられる。 最近多くのサービスがプライバシーポリシーの改定を行っているのはそのためである。個人で作っている自分のサービスにもEUのユーザが沢山いるので、そろそろ対応しなければならない(遅い)。 今回はEUの法律によるものだが、内容は至極真っ当な、客観的に見れば当たり前のルールだ。将来的には事実上のデファクトとなり、アメリカや日本もこの法律に倣うのは時間の問題だろう。だから「日本人向けのサービスだから大丈夫」とほったらかしにしている業者は後々痛い目に遭うだろう。 Twitter社がパスワードをログに記録していた件は記憶に新しいが、今これが公に
認証のグニャグニャ文字は時代遅れ？ GoogleがCAPTCHAを使わなくなったわけ：Mostly Harmless（1/2 ページ） Webサイトの認証などで、人間かAIかの判定に使われている「CAPTCHA」と呼ばれる“グニャグニャ文字”。これをGoogleが使わなくなった理由とは。 少し前、朝日新聞の記事が目につきました。 ネットのグニャグニャ文字認証、AIが楽々突破 「あれ？ これ、前にもあったな」と思って調べてみると、このVicariousがCAPTCHA（Completely Automated Public Turing test to tell Computers and Humans Apart：コンピュータと人を区別するための完全自動化チューリングテスト）を解読したという記事は2013年に出ていました。CAPTCHAというのがこの“グニャグニャ文字”の名前で、主にWeb
パスワードに記号や大文字や数字を盛り込み、定期的に変更するというルールは間違いだったと当事者が告白。
米Yahoo!のメールサービスに使われていたオープンソースの画像処理ツール「ImageMagick」に脆弱（ぜいじゃく）性が発覚し、添付の画像を他人に盗み見される恐れがあったことが分かった。Yahoo!はこの問題への対応として、ImageMagickを引退させることにしたという。 脆弱性を発見したセキュリティ研究者のクリス・エバンズ氏は、この脆弱性を「Yahoobleed #1 (YB1)」と命名した。脆弱性を悪用された場合、初期化されていないメモリを利用してサーバサイドメモリを流出させることが可能だったとされ、「Yahoo! Mail」に添付された画像を他人がYahoo!のサーバから入手できてしまう恐れがあった。 この種の脆弱性ではサーバがクラッシュしないため、「Heartbleed」のような境界外読み込みの脆弱性に比べて、ステルス性が高いという。 エバンズ氏は18バイトの脆弱性悪用ファ
＜アメリカの電子認証専門機関が、定期的なパスワード変更の推奨をやめると決めた。エンドユーザーもいずれ、代わりの新しい「パスフレーズ」を要求されるようになるはすだ＞ 米政府機関はもう、パスワードを定期的に変えるのを推奨しない。アメリカの企画標準化団体、米国立標準技術研究所（NIST）が発行する『電子認証に関するガイドライン』の新版からルールを変更する。 ウェブサイトやウェブサービスにも、サイトが乗っ取られたのでもない限り、「パスワードが長期間変更されていません」などの警告を定期的に表示するのを止めるよう勧告するという。銀行や病院のように人に知られてはいけない個人情報を扱う機関も同じだという。 【参考記事】パスワード不要の世界は、もう実現されている？！ 実は近年、情報セキュリティー専門家の間でも、特別の理由がない限り、ユーザーにパスワード変更を求めるべきではないという考え方が増えてきた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
