Linuxの「SELinux」と「AppArmor」は結局どちらを選ぶべき？
関連キーワード Linux | OS | 運用管理 | セキュリティ OS「Linux」は、複数のセキュリティモジュールを組み込んでいる。アクセス制御を実現するための代表的なセキュリティモジュールが「SELinux」（Security-Enhanced Linux）「AppArmor」だ。「Red Hat Enterprise Linux」（RHEL）およびその派生ディストリビューション（配布パッケージ）はSELinuxを、「Debian」およびその派生ディストリビューションはAppArmorを主に標準セキュリティモジュールとして採用している。両者には、それぞれどのような利点と欠点があるのか。 SELinuxの利点と欠点 併せて読みたいお薦め記事 連載：Linuxのセキュリティを比較 前編：Linuxを守る「SELinux」と「AppArmor」は何が違うのか？ Linuxの運用管理 いま
Webサービスにおけるログイン機能の仕様とセキュリティ観点 - Flatt Security Blog
はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上 @0x003f です。 本稿では、Webアプリケーション上で実装される「ログイン機能」の実装パターンをいくつか示し、その「仕様の中で起きうる脆弱性」とその対策について解説していきます。 「ログイン機能」はToB、ToC問わず多くのWebアプリケーションで実装されている機能で、XSSやSQL Injection、Session Fixationといったような典型的な脆弱性の観点については、なんらかの解説を見たことのある方も多いと思います。 しかし、「仕様の脆弱性」というのはあまり多く語られていない印象です。今回はそのようなタイプの脆弱性についての解説を行います。なお、IDaaSを用いずに自前でログイン機能を実装しているケースを複数パターン想定しています。 はじめに ログイン機能の仕様パターンとセキュリティ
高木浩光氏のワクチン予約サイトの問題への見解
Hiromitsu Takagi @HiromitsuTakagi これはしょうがない。緊急時なのだし（情報漏洩が起きるわけでない限り）このままいくしかない。ただ、こういう事実があることは周知されていた方がよい。 dot.asahi.com/dot/2021051700… 2021-05-17 23:02:01 Hiromitsu Takagi @HiromitsuTakagi 識別符号（アクセス管理者によってその内容をみだりに第三者に知らせてはならないものとされている符号≒パスワード）がないので、不正アクセス禁止法が禁ずる行為には当たらないが、虚偽内容で予約するのは、人の事務処理を誤らせる目的で行えば電磁的記録不正作出・供用罪。 twitter.com/yasushia/statu… 2021-05-17 23:05:37
NIST SP800-207 「ゼロトラスト・アーキテクチャ」の解説と日本語訳
2020年8月、米国国立標準技術研究所（NIST）が「Special Publication（SP）800-207 ゼロトラスト・アーキテクチャ（以下、本書）」を正式公開しました。今回、PwCコンサルティング合同会社はNISTから翻訳の許可を取得し、日本語訳を公開することになりました（以下よりダウンロードいただけます）。 ゼロトラスト･アーキテクチャとは概念であり、また十分に成熟した領域とは言えないため、内容を正しく理解することは容易ではありません。ゼロトラスト・アーキテクチャは製品／ベンダーによって多様な実現方法があるのが実態ですが、対応したソリューションの1つを導入したとしても、ゼロトラスト・アーキテクチャを実現できる訳ではありません。 本書のポイントとして、ゼロトラストの定義や7つの理念を紹介している点が挙げられます。この定義と理念をNISTが整理したことで、ゼロトラストに関する共通
LunascapeとSleipnirに報告した脆弱性の話(スマホアプリではとにかくHTTPSを使え2021)
2021_browser_mitm_vuln.md LunascapeとSleipnirに報告した脆弱性の話(スマホアプリではとにかくHTTPSを使え2021) 前置き この文章と、それに含まれる考察や各サービスへの脆弱性報告などはmala個人の活動であり、所属している企業とは関係ありません。 執筆時点で未修正の不具合や、過去に修正済みで運営元が開示していない脆弱性情報なども含みますが、公益を意図しています。 概要 2020年の年末に、スマホ向けのLunascapeとSleipnirに対して、以下の問題を脆弱性として報告した。 入力途中も含む検索キーワードが、平文で開発元または検索サービスのサーバーに送られる。 利用者が閲覧しようとしたURLが、平文で開発元または検索サービスのサーバーに送られる経路がある。(閲覧URL全部送られたりするわけではない) 2021年の1月に修正されて、修正内容
なりすまし口座に約1億円が流出したSBI証券の不正ログインについてまとめたみた - piyolog
SBI証券は顧客アカウントへの不正ログインにより9,864万円の顧客口座の資産が外部へ流出したと発表しました。資産流出には不正に開設された銀行口座も悪用されました。ここでは関連する情報をまとめます。 SBI証券の発表 悪意のある第三者による不正アクセスに関するお知らせ なりすまし口座を使った犯行 不正利用の手口（SBI証券発表情報よりpiyokango作成）SBI証券からの流出は以下の手口で送金まで行われてしまった。 SBI証券の顧客アカウントに不正ログイン。 偽造した本人確認書類を用いて銀行でSBI証券と同名義の口座を開設。 顧客アカウントが保有する有価証券を売却。出金先銀行口座を不正口座に設定変更。 売却した資金を不正口座に送金。送金された金を引き出し。 約1億円が流出 SBI証券が2020年9月16日時点で把握している被害は顧客数6人、総額9,864万円。1件当たり数百～3,000万
高木浩光＠自宅の日記 - テレフォンバンキングからのリバースブルートフォースによる暗証番号漏えいについて三井住友銀行に聞いた
■ テレフォンバンキングからのリバースブルートフォースによる暗証番号漏えいについて三井住友銀行に聞いた 先週から、「ドコモ口座不正引き出し事件」の原因として、被害の発生した銀行が4桁数字の暗証番号で認証処理していたことが取りざたされており、リバースブルートフォース攻撃の手口が暗証番号特定の手段として使われた可能性について、テレビのワイドショーでも扱われるなど、世間での認知がかつてなく高まっている。 そこで、この機会に、昔から存在していたテレフォンバンキングの危険性について、銀行側に抗議すれば今ならご理解いただけるのではないかと考えた。この問題は十数年前にも銀行側に伝えているが、サービスを止めるわけにもいかないし、電話経由での自動処理による攻撃は考えにくいと当時は考えられたのか、対処されることはなかった。2020年の今日、電話経由のサイバー攻撃は技術面で十分に容易に可能となっていると考えられ
続々連携がストップしているドコモ口座とWeb口振受付の問題について - novtanの日常
詳細不明なところもありますのでなんとも言えないんだけど、外部から見える範囲でわかる問題点について解説してみます。詳細を調べたら問題なかったり、中の人だけが知っている仕様によってクリアされている問題もあるかもしれません。 事実誤認があれば訂正しますのでよろしく。 そもそもドコモ口座って？ ドコモユーザーならおなじみ、それ以外でも使えるアカウントサービスである「dアカウント」に紐づけてキャッシュレス決済などで使用できる電子マネー（だよね）のことです。 dアカウントは元々はドコモ契約者向けのアカウントサービスだったんですが、スマホを起点としたサービスを提供するに当たり、汎用的なアカウントサービス（ID提供サービスとも言えます）にするためにドコモの回線契約とのつながりを限定的にしたものです。GoogleアカウントやFacebookアカウントでのログインと同様、dアカウントでのログインができるように
Hiromitsu Takagi on Twitter: "この指摘が的を射ていると思った。そもそも口座振替って誰にでも振替先となる（自動引き落しさせる）のを認めるものじゃないのでは？公共料金だったりクレジットカードだったり、学会の年会費にも使えたりするが、それなりの組織を介した口座振替依… https://t.co/U2z1Q6da8v"
この指摘が的を射ていると思った。そもそも口座振替って誰にでも振替先となる（自動引き落しさせる）のを認めるものじゃないのでは？公共料金だったりクレジットカードだったり、学会の年会費にも使えたりするが、それなりの組織を介した口座振替依… https://t.co/U2z1Q6da8v
AWSのアカウントセキュリティ本を書きました #技術書典 - プログラマでありたい
2020年2月29日の技術書典8に発表予定だったAWSのアカウントセキュリティ本こと、『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』の執筆が完了し、BOOTHで販売開始しました。 内容 書名のとおり、セキュリティがテーマです。そしてただのセキュリティを題材にすると、いろいろな方面からまさかりが飛んできそうなので、AWSのアカウントセキュリティと限定しています。で、アカウントセキュリティとはなんぞやという話ですが、前作ではAWSを扱う上での認証認可のサービスであるIAMをテーマにしていました。ここをしっかりしていると、ことAWSのアカウントまわりという点では６〜７割くらいはカバーできているのではと思っています。一方で、長く使っていると気が付かぬ穴や、複数人で使って誰かがやらかす人も出てくる可能性があります。この辺りを仕組みとしてカバーできるようにしようというのが、今回のアカ
OAuth2.0を復習してLINEとヤフーの脆弱性見つけたら両社が経営統合された | Nevermoe's Blog
0x00 背景 一 Web Pentester の立場から、毎回 OAuth 連携の案件が来る時に、どこが診断する必要なのか、どこが idP の SDK 使っているから診断不要なのかを見極める必要があり、このような背景において、OAuth2.0 をもう一回復習して、心得を共有したいと思い始めました。（0x01~0x08）。復習しているうちに、OAuth の idP 両社の脆弱性を見つけ、50万円賞金もらって終わりと思ったらいつの間に両社経営統合されました。この話を読みたい方は 0x09 から読んでください。 この文章を読む前提は二つあります： OAuth2.0 の各種認証 Flow (すくなくとも Implicit Grant, Code Grant, Code Grant with PKCE) を大まかに理解していること。 この文章図解：OAuth 2.0に潜む「5つの脆弱性」と解決法に
パスポートのセキュリティ - AAA Blog
前回、運転免許証記載情報の真正性を確認する方法を紹介しました。 パスポートにも免許証と同様にICチップが埋め込まれており、海外渡航時の入国審査では本物のパスポートかどうかチェックが行われています。 不動産取引や民間サービスの本人確認業務でも、同じ方法でICチップの確認を行えば身分証偽造による詐欺行為を防ぐことができます。 今回パスポートのICチップにアクセスして真正性を確認するAndroidアプリをつくったのでその仕組みを紹介します。 目次 電子パスポート仕様パスポートは世界で通用する身分証明書です。 それぞれの国が独自仕様のパスポートを発行すると大変なので、 国際民間航空機関(以下ICAO)がICチップの技術仕様を標準化し、各国のシステムで相互運用できるようになっています。 ICAOはDoc 9303 Machine Readable Travel Documents(機械可読な旅券)と
現場で使えるIoTセキュリティチェックシート、NIST-CSF準拠の第2版を無償公開
現場で使えるIoTセキュリティチェックシート、NIST-CSF準拠の第2版を無償公開：IoTセキュリティ 日本スマートフォンセキュリティ協会（JSSEC）の利用部会は、企業でIoT関連の機器やシステムを導入する場合のセキュリティ検討事項を網羅的にまとめた「IoTセキュリティチェックシート」の第2版をWebサイトで無償公開した。 日本スマートフォンセキュリティ協会（JSSEC）の利用部会は2019年2月28日、企業でIoT（モノのインターネット）関連の機器やシステムを導入する場合のセキュリティ検討事項を網羅的にまとめた「IoTセキュリティチェックシート」の第2版をWebサイトで無償公開した。IoT活用による工場や物流、小売り、オフィスなどのスマート化を目指す企業において、情報システム部門（IT）と設備システム部門（OT）の共通言語となることを目指し「第1版の発表から、3000社以上が加盟する
「さようなら ImageMagick」の考察 - Qiita
はじめに サイボウズさんの ImageMagick の利用をやめる記事について少し思う所を書きます。否定というよりアシストのつもりです。(2018年08月26日投稿) さようなら ImageMagick 自分のスタンスを3行でまとめると、 policy.xml で読み書き出来るファイル形式を絞れば、いうほど怖くはない ただ、ImageMagick に限らずサーバサイドで動かすのは手間と覚悟が要る Yahoobleed の件でコード品質が信用ならないと言われたら、ごめんなさい 「ImageMagick を外した理由」 サイボウズさんのブログでは、2017年の ImageMagick 脆弱性報告数が多いので駄目との事です。 脆弱性 ImageMagick には脆弱性が大量に存在します。 2017 年に報告された ImageMagick の脆弱性は 236 件 でした。 大量にある上にリモートコ
「SSL/TLS暗号設定ガイドライン 第2.0版」を読んで - ぼちぼち日記
1. はじめに 昨日「SSL/TLS暗号設定ガイドライン 第2.0版」が公開されました。 前回から約3年経って今回はCRYPTREC暗号技術活用委員会で検討作業が行われたようです。 普段、TLS/HTTPSの記事を書いたり発表したりしている立場上、これを見逃すわけにはいけません。 本文冒頭では、 「本ガイドラインは、2018 年 3 月時点における、SSL/TLS 通信での安全性と可用性（相互接続性）のバランスを踏まえた SSL/TLS サーバの設定方法を示すものである。」 ということなので、できたてほっかほっかの最新ガイドラインを読ませていただきました。 読み進めてみるとChangelogが細かく書いてなく、以前のバージョンとどこがどう変わったのかよくわかりません。TLS1.3とかは絶対に新しく入った内容なんですが、細かいところはどうだろう… それでも全部(SSL-VPNを除く)をざっと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
もう自宅でも「パブリックネットワーク」が推奨です Windows 11のネットワーク設定画面を確認する【イニシャルB】
サービス終了となった「Smooz」に未修正の脆弱性？ 利用の継続は大きなリスクを負うことに／中間者攻撃により閲覧中WebページのURLを搾取される恐れ
祝RFC！Transport Layer Security (TLS) 1.3 発行の軌跡 ～熟成された4年間の安全性解析～｜株式会社レピダム
前世紀の電話制御技術で、Android端末機器の多くがハッキングできる：研究結果
投機実行の脆弱性修正、Haswell世代以前では性能への影響大 ～I/O集中型アプリケーションを利用するサーバーは慎重な選択を。AMDはほぼ影響受けず
