今さら聞けないセキュリティ　2019年11月06日

C#でバイナリファイルのSHA-256を計算する（実質4行）

.NETやっぱり便利

# たったこれだけ

“`csharp:sha256test.cs

using System;
using System.IO;
using System.Linq;
using System.Security.Cryptography;

class Program
{
[STAThread]
static void Main(string[] args)
{
if (args.Length == 0) { return; }

byte[] byteValue = File.ReadAllBytes(args[0]);
SHA256 crypto = new SHA256CryptoServiceProvider();
byte[] hashValue = crypto.ComputeHash(byteValue);
Console.WriteLine( String.Join(“”, hashValue.Select(x=>x.ToString(“x

ウェブページセキュリティ対策（クリックジャッキング）

フレームの脅威というものをいまいち把握していなかったのですが、
クリックジャッキングというものがあるのですね。

こちらで詳細を把握させていただきました。
>https://blog.tokumaru.org/2013/03/clickjacking-report-by-IPA.html
⇒機能を勝手に実行されるという面で考えると、CSRFと酷似

具体例をだすとこんな感じでしょうか。
①攻撃者が今話題のニュース記事を投稿
　⇒iframeで某通販サイトのページのhtmlを透過で表示し、見た目を変えて画面を表示
②ユーザーが”①”のサイトの次へボタンをクリック（某通販サイトと思わずに）
③結果、某通販サイトを退会させられた

#対策
httpヘッダにX-FRAME-OPTIONSを付与する。
ブラウザが値を検知し、iframeの出力を制限してくれる。

とはいえ、すべてのブラウザがこのhttpヘッダに対応しているかは？なので、
シンプルにCSRFと同じく登録更新系ではトークンを使用するようにしておけば、
安心ではないでしょうか。
退会するには、前画面のトークンが必須など。

んー、if

マルチクラウド環境におけるサーバ証明書の運用　Let’s Encrypt/AWS/Azure

# はじめに
本記事は、マルチクラウド環境におけるサーバ証明書の運用についての記事になります。

マルチクラウド環境でサーバ証明書を使用している場合は、環境によって対応手順が異なります。また、ワイルドカードでサーバ証明書を取得していている場合は、留意事項があるケースが多いので注意が必要です。

本記事では、実際に運用での失敗を経験した上で、サーバ証明書の運用時のポイントなどを簡潔にまとめています。

## サーバ証明書の発行

### Let’s Encrypt
Let’s Encryptでサーバ証明書を発行する場合は、certbotをインストールして発行します。Standaloneプラグインを使用する際は、以下のコマンドを実行します。Webサーバーを停止させずにサーバ証明書を取得したい場合は、Webrootプラグインを使用します。

`# certbot certonly -a standalone -d ＜URL＞ –email ＜メールアドレス＞`

ワイルドカードの場合は、以下のコマンドを実行します。

`# certbot certonly –manual -d ‘*.

「セキュアで堅牢なAWSアカウント」を実現する CloudFormationテンプレート – ②パスワードポリシーの自動修復

# はじめに

AWSにはアカウントやリソースへの脅威検知に対応した、**AWS Security Hub**, **Amazon Inspector**, **Amazon GuardDuty**, **AWS CloudTrail**, **AWS Config** などのサービスが用意されています。

また、[**CIS AWS Foundations Benchmark**](https://d1.awsstatic.com/whitepapers/compliance/AWS_CIS_Foundations_Benchmark.pdf) という**セキュリティガイドライン**が公開されており、このガイドラインは、**AWSアカウントをセキュアに保つために必要なAWSのセキュリティ設定**を集めた**ベストプラクティス集**として活用できます。自身のAWSアカウントがこのガイドラインにどの程度準拠しているのかを確認/監査する手段として、**AWS Security Hub**で、**CIS AWS Foundations Standard**という機能が提供されています。

本

「セキュアで堅牢なAWSアカウント」を実現する CloudFormationテンプレート – ①サービスの有効化

# はじめに

AWSにはアカウントやリソースへの脅威検知に対応した、**AWS Security Hub**, **Amazon Inspector**, **Amazon GuardDuty**, **AWS CloudTrail**, **AWS Config** などのサービスが用意されています。

また、[**CIS AWS Foundations Benchmark**](https://d1.awsstatic.com/whitepapers/compliance/AWS_CIS_Foundations_Benchmark.pdf) という**セキュリティガイドライン**が公開されており、このガイドラインは、**AWSアカウントをセキュアに保つために必要なAWSのセキュリティ設定**を集めた**ベストプラクティス集**として活用できます。自身のAWSアカウントがこのガイドラインにどの程度準拠しているのかを確認/監査する手段として、**AWS Security Hub**で、**CIS AWS Foundations Standard**という機能が提供されています。

本

間違いのないSSH鍵を最速で作成する

ssh-keygenは鍵の強度など、なにかと気を遣うコマンドです。
また、普通に作成するとファイル名やパスフレーズを対話応答で聞かれるので少々面倒ですし、作業メモをとっている場合冗長になります。

2019年版という形にはなりますが、(Githubのドキュメントに従った)一般的と思われる強度を持った鍵を対話応答を省略するオプションを使って作成する方法です。

# 結論
ssh-keygenが使える環境で、<>内を変更して次のコマンドを入力します。
（コメントにはユーザ名やメールアドレスを入れる事が一般的と思います）

“`sh
ssh-keygen -t rsa -b 4096 -C “<コメント>” -f <秘密鍵のファイル名> -N “”
“`

何も聞かれることなく、直ちにカレントディレクトリに次のファイルが作成されます。
./<秘密鍵のファイル名>
./<秘密鍵のファイル名>.pub （公開鍵）

### 使用しているオプション
| オプション | 説明 | 備考 |
|:—|:————-|:————-|
| -t | 鍵の種類を指定

今更だけどDockerコンテナの脆弱性をRancher経由で利用されroot権を渡してしまった話

「脆弱性」というほど大げさなものではなく、Dockerが普及した頃から注意喚起されていた内容ですが、仲間内の環境ということもあり油断していました。今回は戒めの意味も込めて記事を書かせていただきます。

# 使用していた環境
– VPS（2コア/8GB Ubuntu 18.04） *2台
– VPS1台は Docker + Kubernetes を管理するためRancherマスターとして使用
– 残りの1台はRancher管理下のホストとしてKubernetesを構成…デプロイ用
– 権限の状況（どちらもログインできるのは私のみ）
– VPS/Rancherマスター…sudo, docker グループに所属するユーザー1個。公開鍵でのみssh可能
– VPS/ホスト…sudo, docker グループに所属するユーザー1個。公開鍵でのみssh可能
– 環境を使用する人
– 私
– 趣味で一緒にコードを書いている友達
– 環境構築が面倒なのでRancherの構築などは私に投げている

開発チームのための DevOps パイプラインを統合する９つの優れた DevSecOps ツール

[AYALA GOLDSTEIN](https://resources.whitesourcesoftware.com/authors/ayala-goldstein) による [9 Great DevSecOps Tools for Dev Teams to Integrate Throughout the DevOps Pipeline](https://resources.whitesourcesoftware.com/blog-whitesource/9-great-devsecops-tools-for-dev-teams-to-integrate-throughout-the-devops-pipeline) の Google 翻訳（とちょっと校正）です。
2018年6月の記事なので今更感がありますが・・・

—

## 9 Great DevSecOps Tools for Dev Teams to Integrate Throughout the DevOps Pipeline

DevSecOps アプローチを採用するには、組織全体で態度を変える必要があり、プロセ

「世界最悪のログイン処理コード」をセキュアに実装してみる(実装の解説)

この記事は[「世界最悪のログイン処理コード」をセキュアに実装してみる](https://qiita.com/matsumoto_sp/items/3f1e3366078f8181b5d4)の続きです。

## データベースの設定

以下にデータベースで行っている事のうち、重要な部分をピックアップして紹介します。

### テーブル定義

テーブル定義は一般的なアプリケーションと同じで非常に簡単です。データを保存するテーブルは、ユーザーテーブルとフレンド関連テーブルがあれば十分でしょう。以下のように定義しました。

“`SQL
— ユーザーテーブル
CREATE TABLE users(
user_id INT PRIMARY KEY AUTO_INCREMENT — ユーザーID
, login_name VARCHAR (32) NOT NULL — ロクイン名
, profile VARCHAR (200) — プロフィール
, email VARCHAR (40) NOT NULL — メールアドレス
, profile_open ENUM(‘n

「世界最悪のログイン処理コード」をセキュアに実装してみる

しばらく前に話題になった「世界最悪のログイン処理コード」なるものがあります。セキュリティホール満載のログイン処理として有名なコードなのですが、ご存知無い方は是非以下を読んでみて下さい。

* モトネタ
* [This JavaScript code powers a 1,500 user intranet application](https://www.reddit.com/r/programminghorror/comments/66klvc/this_javascript_code_powers_a_1500_user_intranet/)

* 解説記事等
* [世界最悪のログイン処理コード。実際のサービスで可動していたものだとか……](https://twitter.com/hassy_nz/status/1027890455940198400)
* [「世界最悪のログイン処理コード」を解説してみた](https://qiita.com/YSRKEN/items/0095cf75be3f607b0f98)
* [世界最悪のログイン処理コードに関するまとめ]

サーバーレスアプリケーションの最も危険なリスク10選

イスラエルのセキュリティスタートアップ [PureSec](https://www.puresec.io/) による [The Ten Most Critical Risks for Serverless Applications v1.0](https://github.com/puresec/sas-top-10) の Google 翻訳（とちょっと校正）です。

文量が多く、内容も濃いので何度も見返せるように日本語にしました。

序文で述べられているように、このドキュメントでは現時点（原文の最終更新日は2019/3/20）でサーバーレスアーキテクチャに固有のトップリスクと考えられるものを列挙しているということを留意し、実装にあたっては最新のドキュメントを確認することをお勧めします（この翻訳は継続的なメンテナンスを行う予定はありません）。

なお、原文は [Apache License 2.0](https://github.com/puresec/sas-top-10/blob/master/LICENSE) です。

—

# サーバーレスアプリケーションの最も重大なリス

初学者のVPSサーバー構築手順書(3)

それではセキュリテー強化のために以下を実行していきます。

・ 一般ユーザの作成
・ 公開鍵認証の設定
・ sudo 設定
・ SSH 接続時、root でのログインを禁止
・ SSH 接続時、パスワード認証を禁止

#一般ユーザーの作成

一般ユーザの作成は「useradd」コマンドを使う。

“`
$ ssh root@[IPアドレス]
root@[IPアドレス]’s password:
Last failed login: Sat Oct 19 22:34:57 JST 2019 from 218.92.0.171 on ssh:notty
There were 621 failed login attempts since the last successful login.
Last login: Sat Oct 19 17:35:04 2019 from kd0000000000.ppp-bb.dion.ne.jp

SAKURA Internet [Virtual Private Server SERVICE]

[root@tk0-000-00000 ~]# use

Webアプリケーションのメジャーな脆弱性とその対策

社内勉強会用にWebアプリケーションにおけるメジャーな脆弱性についてです。
[セブンペイ・PayPayから学ぶ認証セキュリティ](https://qiita.com/YutaSaito1991/items/9a9c3f1966e23af7e42c)では認証セキュリティについて触れていますので興味があればどうぞ。

## SQLインジェクション
SQLインジェクションは、アプリケーションが想定しているSQLとは別のSQLを実行させるように操作する攻撃です。

掲示板機能を例にします。

“`sql:DBの内容
mysql> select * from posts;
+—-+—————+———-+———————+———————+
| id | email | body | created_at | deleted_at |
+—-+—————+———-+———————+—

実際にCSRF攻撃してみた

#はじめに
CSRFについて解説している記事はたくさんありますが、具体的にどのような方法で攻撃されるのかを
解説している記事は少ないと思います。
そこで、今回は実際に脆弱なwebサイトを作り、それに対してCSRF攻撃を仕掛けてみたいと思います。

#CSRFとは
CSRF(クロスサイトリクエストフォージェリ)は、webサービスの脆弱性を利用したサイバー攻撃の一種です。
標的となるwebサービスにログイン中のユーザーが、悪意のあるURLを開いた場合にユーザーの意図しないリクエストを標的webサービスに送信されてしまう攻撃です。
文字で表現しても伝わり辛いので実際に動作を確認してみましょう。

#環境
・CentOS 7.7.1908
・Apache/2.4.6
・PHP 7.2.23
・MySQL 5.7.28

#前提
PHPで以下の機能を持った今回の標的となる脆弱性のある簡素な掲示板アプリを用意しました。
・会員登録
・ログイン
・ログアウト
・コメント投稿
・コメント一覧表示

#攻撃イメージ

Volatility3を早速使ってみた[追記]

# volatility3
昨日の[OSDFCon](https://www.osdfcon.org/)でVolatility3が発表されました。発表されたVolatility3を使っていきたいと思います。

# 検証環境
用意したものは以下になります。
– ~~Ubuntu 18.04~~
– Ubuntu 19.10

# インストール
基本的にVolatility以外はpip3でインストールしました。
1. Pefileのインストール

> pip3 install pefile

2. yaraのインストール

> pip3 install yara-python

3. capstone のインストール

> pip3 install capstone

4. volatilityのダウンロード

> git clone https://github.com/volatilityfoundation/volatility3.git

# 実行
ヘルプを実行！

> $ python3 vol.py -h

コマンドからプラグインに変更となっているみたいで、それぞれの

AWS 認定セキュリティ-専門知識　合格体験記

#0．はじめに
どうも。大変ご無沙汰しています。[zd6ir7](https://qiita.com/zd6ir7)です。前回の投稿[「バカなことに・・・AWS EC2にssh接続できず超ハマった小話」](https://qiita.com/zd6ir7/items/6b9a7ef483e69585ea35)から間が空いてしまいました。
この度2019年9月に[AWS 認定セキュリティ-専門知識](https://aws.amazon.com/jp/certification/certified-security-specialty/)に合格することができましたので、今回ここに合格体験を記載します。今後受験される方の参考になればと思います。

#1．筆者(受験者)の基礎情報

1. ####業務略歴
キャリアの大半はプロジェクトマネジメントに従事。ここ数年はインフラ構築プロジェクトに携わってきた。

2. ####AWS経験
2018年11月からAWSについて勉強開始。2019年1月にAWS 認定ソリューションアーキテクト-アソシエイトに合格([AWS 認定ソリューションアーキテクト

SSL/TLS、HTTPS、サーバー証明書を理解したい

##はじめに
SSL/TLS、HTTPSについてざっくり理解したのでまとめました。超ざっくりです。
間違っている箇所があれば指摘いただけると幸いです。
前半で用語解説、後半で図解しています。

##SSL/TLSとは
*SSL(SecureSockets Layer)/TLS(Transport Layer Security)*
SSLとTLSは別物だが、どちらも安全な通信のためのプロトコル（決まり）。
SSLが先に開発されたが、SSLに重大な脆弱性が発見されたため、後継としてTLSが開発された。
いま現在使用されているプロトコルはTLSだが、便宜上SSLやSSL/TLSと呼ばれている。
サーバ証明書、公開鍵、秘密鍵、共通鍵を用いた暗号化方式。

##HTTPS通信とは
SSLで暗号化されたHTTP通信のこと。
HTTP over SSL/TLS→HTTPS
HTTPS通信を行うサーバーにはサーバー証明書と秘密鍵を含むファイル群をインストールする必要がある。
最近のGoogle Chromeでは、すべてのページがSSL化されていないサイトには「保護されていない通信」という旨の警告が出

標準Windowsで追加インストールなしの暗号化ソリューションを作ってみた

# はじめに

いつの頃からか、Windowsからパスワード付きZip作成の機能がなくなってしまっています。
そのため、安全にファイルを取引先などに渡すために、追加のソリューションの導入が必要です。

ところが、相手先によっては会社で許可されているソフトウェア以外は勝手にインストールできない場合があります。
あるいは、ITリテラシーの低い取引先または担当者の場合、こちらの推奨するアーカイブソフトを導入してもらうのも、またひと苦労かかります。

つまり、Windowsにファイル受け渡しのための暗号化（自分のストレージを守るディスク暗号化はありますが）ツールが標準で用意されていない、というところに問題があるわけです。

そこで、タイトルにあるように（実際は「ソリューション」という程大げさなものではないのですが）作ってみました。

# AES暗号化をWindowsの標準機能だけで実現するツールを作った

このツールは、以下の要件を満たします。

– AES暗号化によるパスワード付きZip以上の安全性
– 十分な桁数の堅牢なパスワードをツールが自動生成
– Windows10なら追加インストー

phpdotenvについて。

[phpdotenv](https://github.com/vlucas/phpdotenv)について勉強しようと思ったのですが、全体的な説明をしてくださっている記事が見つからなかったので、自力で公式のREAD ME.mdを日本語に訳しました。
前提知識が必要そうなワードは太字にして、参考になりそうな記事のリンクを追記しています。（PHPの[公式マニュアル](https://www.php.net/manual/ja/index.php)は日本語の説明文が難解なのでリンクを張っていませんが、適宜そちらも読みながら理解することをオススメします。）

当方、勉強中の者ですので、不適切な表現がある箇所はバシバシご指摘ください！
（特に、**Loader Customization**の項がほとんど理解できていないため、ご指摘お待ちしております。）

(2019年10月執筆)

# PHP dotenvとは
PHP dotenvは、Ruby言語で使われている**[dotenv](https://github.com/bkeepers/dotenv)**のPHP版です。

`getenv()`

PaloaltoとFotiGateのログ分析における注意点

UTM市場で市場展開が盛んな2つのベンダーのUTM製品においてログ分析を行う際、注意するべきことがあるため記載します。
ログ分析の観点から結構インパクトがある内容であるため気をつけたほうがいいかもです。

# FortiGate
6.0.4以降及び6.2.0以降から記載される内容の考え方が大きく変わります。
以下は説明する上で出てくる単語と意味、key=value形式のkeyフィールド名

> – 送信元情報
> – 送信元IP[srcip]
> – 送信元インターフェース[srcintf]
> – 送信元インターフェースロール[srcinfrole]
> – 宛先情報
> – 宛先IP[dstip]
> – 宛先インターフェース[dstintf]
> – 宛先インターフェースロール[dstintfrole]
> – 方向情報
> – 方向[Direction]
> – 悪意あるサーバー情報
> – IP：a.a.a.a
> – インターフェース：port1
> – インターフェースロール:WAN
> – 攻撃を受ける端末の情