今さら聞けないセキュリティ 2020年03月20日

今さら聞けないセキュリティ 2020年03月20日
目次

WEBアプリのログイン機構のセキュリティチェック観点

ログイン関連の機能開発するときに、私が確認している項目

**[重要!!]金融、行政システムなど、業界独自の法規・基準は意識していません**

## 結論

もろもろいろいろ面倒なので、ログインロジックの自作は極力避けましょう。
SNSとかのソーシャルログインがいいです。
作るの大変ですけど、運用が相対的に楽になります。

あと、不必要に個人情報持つのもやめましょう。
持っちゃうと後が大変です。。。

## リスク評価観点

* ログインユーザに紐づけて以下の情報を保持するか?
* 個人情報
* 個人を特定可能な情報
* メールアドレスだけでも個人情報
* cf. https://www.soumu.go.jp/main_sosiki/gyoukan/kanri/question03.html
* 総務省では、「メールアドレスだけでも個人情報になる場合がある」としているので、
そういったアドレスを排除できない以上、メアドだけでも個人情報を持っていることになる
*

元記事を表示

【Sign in with Apple】「xxxxx@privaterelay.appleid.com」へメールを送った際バウンスする

# はじめに
Sign In with Apple(Appleログインと後述)が2019年に発表され、2020年4月には必須化になるなか導入の際にハマったインフラ系のことについてメモ書きしておきます。
私はiOSエンジニアではないですがPMやっていたときに遭遇しました。
ユーザ登録時にAppleログインで会員登録する際にメールアドレスをサービス提供側に公開するか非公開にするか選択があります。
非公開を選択した場合、サービス側が取得できるメールアドレスは「xxxx@privaterelay.appleid.com」になります。
本家サイトには「xxxx@privaterelay.appleid.com」に返信すれば登録ユーザに届くというようなことを書いているけどもGmailで送信した場合に下記の様にバウンスしてきました。これの解決方法です。

![apple_bounse.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/397770/7be4cf0d-d06b-67df-59e2-edc3420929f0.

元記事を表示

セキュリティマネジメントの勉強-リスク分析と評価

#リスク分析と評価
リスクマネジメントを行うためには、情報資産を調査し分類する必要がある。
それを情報資産台帳にまとめる。

##情報資産の調査
ISMSの適用範囲で用いられている情報資産の調査を行う。
部門ごとに漏れの内容にリスクを洗いだす。
過去の事件や事故、損害額なども考慮し、脅威と脆弱性を認識する。

##情報資産の重要性による分類と管理
単独で管理すると分析がつらい。
そのためグループ化して管理する。

##情報資産台帳
機密性や重要性、分類グループなどをまとめたのを情報資産台帳という。
情報資産をもれなく記載するだけでなく、変化に応じて適切に更新していくことも必要。

#リスクの種類
##リスク
リスクとはまだ起きてはないが、起こると情報資産に影響を与える事象や状態のこと。
すでに起こったことはリスクではなく問題として処理する。
また起こっていない、起こるかどうかが不確実なことを、リスクとして洗い出す。

##リスク源
リスク発生源(リスクソース)を除去することが有効なリスク対策となる。

##リスク所有者
リスクを洗い出し、リスクとして特定したら、リスク所有者を決定する

元記事を表示

セキュリティマネジメントの勉強-情報セキュリティ継続

#情報セキュリティ継続
##緊急事態の区分
緊急事態の区分を明らかにしておく必要がある。

| レベル |事象 |
|—————–:|:——————:|
| 1 | 影響を及ぼすおそれのない事象 |
| 2 | 影響を及ぼすおそれの低い事象 |
| 3 | 影響を及ぼすおそれの高い事象 |

##緊急時対応計画
Contingency Plan
サービスの中断や災害発生時に、システムを迅速かつ効率的に復旧させる計画。

初期の対応計画では、初動で何をするかなどを中心に組む。
完全復旧よりも暫定対応を優先することもある。

##復旧計画
緊急対応後、完全復旧させるための計画です。
暫定的ではなく、恒久的な復旧を目指す。

##障害復旧
日頃からバックアップを取っておくこと。
バックアップデータはシステムのそばに置いてるほうが復旧が早いが
地震とかの大災害時を想定すると、遠隔地に保存しておくことも必要。

##ディザスタリカバリ
事業継続マネジメントのおける概

元記事を表示

情報共有ツールで意図しない情報漏洩を防ぐための設定

## はじめに
開発に限らず様々なプロジェクトで、Google DriveやTrello等のチーム内情報共有を円滑にするためのツールを使う機会は多いと思います。
ただ、うっかり設定を誤ってしまうと思わぬところで情報漏洩をしてしまうことなどがあります。
本記事ではそのような誤りがないように設定する手順をまとめます。

## Google Drive
#### リンク共有による意図しない情報漏洩を防ぐ
チーム内でファイルを共有するためにリンクURLを共有することがあると思います。
この共有可能リンクはデフォルトで「リンクを知っている人は**誰でも**アクセス可能」となるため注意が必要です。

##### リンク共有手順

(ファイルを開いた状態の場合)
「共有」をクリックします。
スクリーンショット_2020-03-16_10_03_55.pngSpring SecurityでDB認証&BCryptでハッシュ化

# 概要
* Spring Securityで必要最低限のログイン機能を実装する。(権限周りは触れません。)
* ログインフォームなどはSpring Securityで用意されているものを使う。
* 仕組みはあまり理解できていないので、また別でまとめます。
* この投稿はとりあえず、動くようになったというところまで!

# 開発環境
* OS:Windows10
* IDE:eclipse 2019-12
* Java:13
* Spring boot:2.2.5(Gradle)
* DB:Oracle 12c

# Spring Securityの導入
## 依存関係で下記の4つを選択
* Spring Security
* Spring Web
* Spring Data JPA
* Oracle Driver ←使用するDBのDriverを選択してください
![2020-03-15-14-06-34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/364697/5974c5b7-

元記事を表示

[月次配信] 月次攻撃サービスの統計及び分析 – 2020年2月

#はじめに
株式会社サイバーフォートレスでは攻撃サービス(ポート)情報を収集し、分析しています。
分析内容から、月次攻撃サービス(ポート)、月次攻撃サービスパターンのTOP10を確認し、過去データと比較し、攻撃トレンドへの対策を考えます。
セキュリティ担当者または、システム管理者はこのようなデータ分析を活用してサイバー脅威の予測に役立てていただければと思います。

#月次攻撃サービス(ポート)TOP 10
2020年2月の一か月間収取されたイベントの分析結果、先月とほぼ同じ推移でみられている。月次攻撃サービスTOP 10は、全体の件数と比べて減少した。全体的な特異事項はない。

| 順位 | サービス(ポート) | 比率(%) |
|:—-:|:———————:|:——-:|
| 1 | HTTP(TCP/80) | 45.75% |
| 2 | DNS(UDP/53) | 18.17% |
| 3 | Microsoft-DS(TCP/445) | 15.12% |
|

元記事を表示

自動車の電源・電池と計算機・通信

自動運転系の安全分析をするにあたり、電気自動車の電源・電池と計算機・通信について網羅的な調査を始めるために、

「自動車 複数電池」で検索した。

主な検索結果と、その記事中で参照している一次情報、参考文献などを列記する。

これは、自動車の安全を確保するためには、通信・サーバ、ECU(CPU)などが乗っ取られないことが重要であるが、これまでの安全対策で漏れているところがないかを探す作業の一つである。

#1.
自動車用リチウムイオン電池を活用した 電源システム, 境野 真道, 九州工業大学/日産, 2015
https://kyutech.repo.nii.ac.jp/?action=repository_action_common_download&item_id=4509&item_no=1&attribute_id=16&file_no=1

参考文献
[1] (社)次世代自動車振興センター, “電気自動車等保有台数統計(推定値)” [オンライン]. Available: http://www.cev­pc.or.jp/tokei/hanbai.html [アクセス日:

元記事を表示

「3分で理解するWEBプログラミングセキュリティ 02」クロスサイトスクリプティングとは?

# 3分で理解するWEBプログラミングセキュリティ 02
**3分で理解するWEBプログラミングセキュリティ**
↓↓記事が出来次第Link貼って行きます↓↓
**No.01 SQLインジェクションとは?**
**No.02 クロスサイトスクリプティングとは?**
**No.03 クロスサイトリクエストフォージェリとは?**
**No.04 ディレクトリトラバーサルとは?**

1.クロスサイトスクリプティングとは?
・概要
2.クロスサイトスクリプティング対策(PHPでの実装例)
・対策方法
・実装例

##1.クロスサイトスクリプティングとは
**概要**
攻撃者は、まずターゲットとなる企業を見つけ、その企業に興味を持ちそうなユーザーが訪れる掲示板サイト上で罠(スクリプト付リンクを貼るなど)を仕掛けます。ターゲットの企業に興味を持ったユーザーが、掲示板サイト上で仕掛けられた罠にかかると、攻撃者が掲示板サイト内でスクリプトを実行します。
ユーザーはスクリプト情報を持ったままターゲット企業のページに移動することになるのですが、実は、ジャンプ先はターゲット企業を装った偽サイトで

元記事を表示

Linuxでファイル入出力のログを取りたい

#やりたいこと
ユーザがPCとUSBメモリやSDカードをつないでデータを出し入れした時の
ログをとりたい。また、勝手にユーザが監視プロセスを落とせないようにしたい。
#インストール
inotify-toolsをインストール

“`
sudo apt-get install inotify-tools
“`
#試してみる
“`
qiita@ubuntu:~$ inotifywait -m .&

“`
mオプションをつけないと、1回出力するとコマンドが終了するとのこと。

“`
qiita@ubuntu:~$ ls
Desktop Documents Downloads Music
./ OPEN,ISDIR
./ ACCESS,ISDIR
./ CLOSE_NOWRITE,CLOSE,ISDIR
qiita@ubuntu:~$
qiita@ubuntu:~$

“`
lsで監視しているディレクトリにアクセスすると何か表示されている。

サブディレクトリはどうだろう

“`
qiita@ubuntu:~$ mkdir hoge
./ CREATE,ISDIR

元記事を表示

[Python] Pythonとセキュリティ – ③Pythonで作るSQL Injectionツール

#はじめに
前回([[Python] Pythonとセキュリティ – ②Pythonで作るポートスキャニングツール](https://qiita.com/CyberFortress/items/0c18f0d773ad51ba9b78))でPythonを利用して簡単なポートスキャニングツールを作ってみた。
今回はウェブ脆弱性の中で重要度が高い「SQL Injection」の理解を深める為、ツールを作ってみよう。

**許可を得ていない対象に実施するのは犯罪です。当該の記事で問題が発生した場合、弊社では一切責任を負い兼ねますのでご了承ください。**

#SQL Injectionとは
SQL Injectionは「Injection」攻撃の一つの種類で、クライアントの入力値がサーバのデータベースに送信され、データーベースの操作、破棄、漏洩などを行う攻撃方法である。攻撃方法の難易度は低いがデータベースを直接攻撃するため、被害が大きい攻撃である。このようなInjectionの脆弱性の場合、スキャニングツールなどで発見される場合が多いため、ウェブの担当者は必ず完成されたウェブページにスキャニン

元記事を表示

リモートワーク環境で、危険なURLを検出できているのだろうか

### 忙しい人へ
* リモートワークの環境によっては、社内の出口対策を経由できずに、インターネットに出る可能性があると思います
* その場合、入り口対策をbypassできてしまうと、ちょっと危ないのではないでしょうか
* 今回は、それをURLに限って記載した記事です
* オリパラまでに安全なインターネットが実現されれば嬉しいなと思います
* 技術がわかる人は、[バックスラッシュの含めたURLからドメイン名が抽出できない件](https://qiita.com/hinoshiba/private/b158a8b4ca522e90fdfa#%E3%83%90%E3%83%83%E3%82%AF%E3%82%B9%E3%83%A9%E3%83%83%E3%82%B7%E3%83%A5%E3%81%AE%E5%90%AB%E3%82%81%E3%81%9Furl%E3%81%8B%E3%82%89%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E5%90%8D%E3%81%8C%E6%8A%BD%E5%87%BA%E3%81%A7%E3

元記事を表示

OmniAuth の `/auth/:provider` で GET を受け付けるのはやめましょう (あるいは CVE-2015-9284 について)

# tl;dr

* OmniAuth を使う場合、まずはユーザーを `/auth/:provider` のような URL に誘導すると思います。
* このパスで GET リクエストを受け付けることは、セキュリティの観点から推奨されていません。
* 具体的には、ユーザーが意図しないうちに、意図しない外部アカウントを紐付けてしまう危険性があります。
* 代わりに POST を受け付けるようにしましょう。

# どんな問題が発生するの?

## 前提

Web サイト A と B が存在するとします。
Web サイト A は OmniAuth を使って、「B のアカウントでログイン」のような機能を実装しています。そして `/auth/site_b` で GET リクエストを受け付けています。

アリスとマロリーがいるとします。アリスは被害者、マロリーは攻撃者です。
アリスは A のアカウントを持っていて、A にログイン済みですが、B のアカウントは紐付けていません。マロリーは B のアカウントを持っていて、あらかじめ A に対する認可を済ませてあります [^1] 。

## 攻撃開始

元記事を表示

AWSの多要素認証について

##AWSでは多要素認証が使えます
最近現場でAWS(Amazon Web Service)に触れる機会があり、
私が使っているIAMユーザでもログインをする際に多要素認証を行っております。

この多要素認証ひと手間かかりますが、
このひと手間で情報漏洩しない(に等しいほど可能性を低くできる)と考えればやらない手はありません。

ではこの多要素認証ですが、AWSでは以下の4つが使えます。
(1つは廃止されましたが…)

・SMSテキストメッセージベースMFA(廃止)
・U2Fセキュリティキー
・ハードウェアMFAデバイス
・仮想MFAデバイス

##その前に①:多要素認証とは

4つの多要素認証…、
多要素認証ってさっきから言っているが、それはなんだ?という方に簡単な説明を。

多要素認証は言葉の通り多数(複数)の要素で認証を行うことです。

要素は主に3つあり、
「知識要素(パスワード等)」「所持要素(セキュリティトークン等)」
「生体要素(指紋等)」という要素があります。
このうちの2種類以上を使用して認証することを多要素認証といいます。

また英語でMulti-factor

元記事を表示

JavaScriptの問題 「DOM Based Xss / Webストレージの不適切な使用」

JavaScriptにまつわる脆弱性について。
「DOM Based Xss」と「Webストレージの不適切な使用」について記載する。

[JavaScript | MDN](https://developer.mozilla.org/ja/docs/Web/JavaScript)

#DOM Based Xs

1. 概要
2. 攻撃手法と影響
3. 脆弱性が生まれる原因
4. 対策

[DOM Based XSS – IPA](https://www.ipa.go.jp/files/000024729.pdf)
[第6回 DOM-based XSS その1:JavaScriptセキュリティの基礎知識|gihyo.jp … 技術評論社](https://gihyo.jp/dev/serial/01/javascript-security/0006)

##概要
JavaScriptが原因で発生するXXSをDOM Based Xssと呼んでいる。
XXSはサーバ側のプログラムの不備が原因で発生するが、クライアントサイドで動作するJavaScriptの記述の不備で発生するケースもある。

元記事を表示

Linuxセキュリテイ対策 ホストの侵入検知(chkrootkit/rkhunter/maldetect)

# はじめに
本記事はLinuxのセキュリティ対策として、ホストの侵入検知について記載しています。

ホストの侵入検知の目的は、ルートキットの存在やマルウェアを検知することです。

本記事では以下のツール(※)を扱います。

– chkrootkit
– rkhunter
– maldetect

(※)バージョンについては本記事執筆時点の最新バージョンを使用

## chkrootkit
chkrootkitはルートキットの存在を検知するためのツールです。
CentOSの標準リポジトリには、Ubuntuのようにchkrootkitのパッケージは含まれていません。

chkrootkitは[chkrootkit.org](http://www.chkrootkit.org/)の[Download](http://www.chkrootkit.org/download/)からダウンロードできます。
本記事ではCentOS 7を例にchkrootkitの導入手順について解説します。

なお、chkrootkitは以下のコマンドを使用します。既に改ざんされた後では意味がないため、導入時には考

元記事を表示

ID インフラストラクチャをセキュリティ保護する 5 つのステップを読み解く

#はじめに
今から書く内容は、Microsoft の公開情報である「ID インフラストラクチャをセキュリティ保護する 5 つのステップ」の内容をかみ砕いて書いています。

-参考情報
ID インフラストラクチャをセキュリティ保護する 5 つのステップ
URL:https://docs.microsoft.com/ja-jp/azure/security/fundamentals/steps-secure-identity

以下の設定を施したからといって、セキュリティ保護が万全になるわけではありません。
逆に以下の設定を必ずしもすべて設定しないといけない、というわけでもありません。

この記事を書いた意図としては、ID を正しく保護するための方法が複数用意されているので、ご利用の環境に合わせて選択していただくための一助にして欲しいからです。

下記 Microsoft 公開情報にベストプラクティスとして書かれている記事がありますので、そちらも参考にしてみてください。

-参考情報
Azure の ID 管理とアクセス制御セキュリティのベスト プラクティス
URL:https://doc

元記事を表示

IAMベストプラクティスにほぼほぼ準拠したIAMユーザ・グループ作成と、MFA デバイスの自己管理を許可するポリシーの取り扱い注意点

# 1. はじめに
* AWS マネジメントコンソール作業で使用するIAMグループ や IAMユーザーの設計や作成フローを、[IAM ベストプラクティス](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html) を参考にして見直してみる。
* けど、IAMグループ や IAMユーザー の作成に関する [IAM ベストプラクティス](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html) をすべて採用するのは窮屈なので、採用するものを決めて My IAM プラクティスを作成してみる。
* そして、My IAM プラクティスに準拠したIAM グループ、IAMユーザーの作成フローを構築してみる。
* 例として、新規に参画したAWS マネジメントコンソール作業者で、開発チームのAさんの IAM ユーザーを作成してみる。
* あと、IAMポリシーとIAMグ

元記事を表示

AWS Well-Architected Framework「セキュリティ」

セキュリティの柱の7つの設計原則をざっくりまとめてみたいと思います。
この内容はnoteのほうで投稿したものと同じ内容になります。
「[②最重要項目:セキュリティ](https://note.com/yoriasanuma/n/n9df28ba45578)」

####1, 強力なアイデンティティ基盤の実装

アカウントの用途によって与える操作権限を分けましょう。システムを管理するためのアカウントには設定変更・リソースの追加・削除ができる権限を与え、その他のアカウントには設定値やリソースの使用状況の参照のみできる権限を与えるなど、必要最低限の権限のみ与えるようにします。また、多要素認証(自分で設定したパスワード+一時的に発行される認証コードなど)を利用することでセキュリティを向上できます。権限を一元管理し、認証情報も適切に管理しましょう。

####2, トレーサビリティの実現

だれが、いつ、どんな操作をしたかを常に監視し、ログとして記録しましょう。AWSサービスを組み合わせて、不正なアクセスやリソースの状態の変化をリアルタイムで検知し、自動でアクションを実行させることができます。

元記事を表示

Linuxの監査システム Auditについて理解する

# はじめに
本記事はLinuxの監査システムであるAuditについて記載しています。

AuditはLinuxの監査システムとして、監査ルールを定義し、システムで発生したセキュリテイに関するイベントをログファイルに出力します。

ログファイルに出力されたメッセージを監視することで、セキュリテイに関するイベントを検知することができます。

Auditでは以下の監査ルールが設定可能です。

– 制御ルール
– システムコールルール
– ファイルシステムルール

## Auditの概要
Auditはauditdデーモンとして起動し、カーネルから受け取った監査結果をログファイルに出力します。

全般的な設定は`/etc/audit/auditd.conf`ファイルで設定します。

– /etc/audit/auditd.conf

“`text
#
# This file controls the configuration of the audit daemon
#

local_events = yes
write_logs = yes
log_file = /var/log/audi

元記事を表示

OTHERカテゴリの最新記事