「ALBでHTTPS化したのに、なぜ後ろにいるECSコンテナはポート80（HTTP）のままで通信できるんだろう？」

この一見不思議な挙動は、ALBが持つ2つの重要な役割を理解することで、スッキリと解決します。今回は、このALBの「魔法」の仕組みを、セキュリティグループの設定から紐解いていきましょう。

最終的な構成：安全な3層アーキテクチャ

まず、私たちが目指すのは、セキュリティと可用性のベストプラクティスに基づいた、以下のような3層アーキテクチャです。

• Web層: ALBがインターネットからのリクエストをすべて受け付けます。
• AP層: ECSコンテナがプライベートな領域でアプリケーションを動かします。
• DB層: RDSがさらに内側のプライベートな領域でデータを安全に保管します。

この構成のセキュリティの肝は「ECSはALBからの通信しか受け付けない」というルールです。これを実現するのが、次に説明するセキュリティグループです。

門番の役割を担う「セキュリティグループ」

セキュリティグループは、リソースのドアを守る「バーチャルな門番」です。今回は3人の門番を配置します。

1. ALBの門番: インターネットからの訪問者（ポート80, 443）を全員受け入れます。
2. ECSの門番: ALBの門番から紹介された人（ALBからのトラフィック）だけを通します。それ以外の人は全員お断りです。
3. RDSの門番: ECSの門番から紹介された人（ECSからのトラフィック）だけを通します。

この連携により、たとえ攻撃者がECSに直接アクセスしようとしても、門前払いされる仕組みが完成します。

ALBがこなす2つの全く異なる仕事

さて、ここからが本題です。ユーザーがhttp://でアクセスしてきた時に、ALBとコンテナの間で何が起きているのでしょうか。実は、これは2段階の独立した処理になっています。

ポイントは役割が2つ存在するということです。

ブラウザへの「リダイレクト指示」

最初のやり取りは、ユーザーのブラウザとALBの間だけで完結します。

1. ユーザー: ブラウザで http://example.com (ポート80) にアクセス。
2. ALB (ポート80の受付係): リクエストを受け取ると、中身は見ずにこう応答します。「すみません、こちらの窓口は安全ではありません。向かいにある安全な443番の窓口へ行き直してください」。これがHTTP 301リダイレクトです。

この時点では、リクエストはまだECSコンテナには一切届いていません。

ステップ2：コンテナへの「リクエスト転送」

ブラウザはALBからの指示に従い、今度は最初から安全な窓口へ向かいます。

1. ユーザー: ブラウザが自動的に https://example.com (ポート443) に新しいリクエストを送信します。
2. ALB (ポート443の受付係):
   • 暗号化されたリクエストを受け取り、持っているSSL証明書を使って通信を復号します（SSL/TLS終端）。
   • 安全な平文になったリクエストを、宛先であるECSコンテナのポート80へ転送（フォワード）します。
3. ECSコンテナ (ポート80): ALBから来た通常のHTTPリクエストを受け取り、処理を実行します。

このように、ALBはユーザーを正しい入口へ案内する「案内係」の仕事と、リクエストを内部の担当者へ届ける「取次係」の仕事という、2つの全く異なる役割をこなしているのです。

コンテナからすれば、常にALBという信頼できる取次係から、暗号化が解かれた分かりやすいリクエストが届くだけなので、ポート80で待ち受けていれば良い、というわけです。

非常に便利ですね。。

CDKの実装

SecurityGroup の実装

// ALB用セキュリティグループ
const albSecurityGroup = new ec2.SecurityGroup(this, 'AlbSg', { vpc });
albSecurityGroup.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(80), 'Allow HTTP');
albSecurityGroup.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(443), 'Allow HTTPS');

// ECS用セキュリティグループ
const ecsSecurityGroup = new ec2.SecurityGroup(this, 'EcsSg', { vpc });
// ALBからの通信のみを、コンテナのポート80で許可
ecsSecurityGroup.addIngressRule(
    albSecurityGroup,
    ec2.Port.tcp(80),
    'Allow traffic only from ALB'
);

ALBリスナー

// ALB本体を作成
const alb = new elbv2.ApplicationLoadBalancer(this, 'MyAlb', {
    vpc,
    internetFacing: true,
    securityGroup: albSecurityGroup,
});

// HTTPリスナー (ポート80): HTTPSへリダイレクトするだけ
alb.addListener('HttpListener', {
    port: 80,
    defaultAction: elbv2.ListenerAction.redirect({
        protocol: 'HTTPS',
        port: '443',
        permanent: true,
    }),
});

// HTTPSリスナー (ポート443): ECSへリクエストを転送する
alb.addListener('HttpsListener', {
    port: 443,
    certificates: [certificate], // ACMで発行した証明書
    defaultAction: elbv2.ListenerAction.forward([ecsTargetGroup]), // ECSのターゲットグループ
});

まとめ

• ALBのHTTP→HTTPSリダイレクトは、「リダイレクト指示」と「リクエスト転送」の2段階で行われる。
• SSL/TLSによる暗号化・復号の処理はALBがすべて肩代わりしてくれる（SSL/TLS終端）。
• コンテナは、ALBから転送されてくる暗号化されていないHTTPリクエストを受け取るだけで良い。
• セキュリティグループを正しく設定することで、この安全な通信経路が完成する。

役割が2つあることが分からなければ理解できなかったなぁ。

参考記事

RESTful APIは、ウェブアプリケーションやウェブサービスで使われるプログラミングインターフェースです。
REST（Representational State Transfer）の原則に基づいて設計されており、ウェブ上のリソースへのアクセスや操作を統一的な方法で提供します。
リソースはURLで識別され、HTTPメソッド（GET、POST、PUT、DELETEなど）を使ってアクセスされます。

[getpost id=”1672″ cat_name=”1″ date=”0″]

SPA（シングルページアプリケーション）とは？

SPAは、ユーザーがアプリケーションを操作する際にページの再読み込みをせずに、必要なデータのみをサーバーから非同期に取得し、動的にページの内容を更新するウェブアプリケーションの形式です。

これにより、従来のマルチページアプリケーションに比べてユーザーエクスペリエンスが向上します。

僕が所属しているチームでもページのリロードが嫌だというユーザーの使用感からSPAへの移行が少しづつ始まってきています。
世間的にもSPAは流行っていますよね。（流行っているから偉いというわけではない。知ることが大事

RESTful APIとSPAの関係性

SPAでは、ページの初回読み込み時にアプリケーションの全てのコード（HTML、CSS、JavaScript）がロードされます。

その後のユーザーの操作によってデータが必要になる場合、SPAはRESTful APIを通じてサーバーからデータを非同期に取得します。
このデータはJSONやXML形式で返され、JavaScriptを用いてクライアントサイドで処理され、ページの一部分だけが動的に更新されます。

このアーキテクチャにより、SPAはユーザーにスムーズで反応の良いインターフェイスを提供できます。

RESTful APIはこのプロセスの背後にあるデータ通信の基盤となります。

PHPとReactを使った例

ここでは、PHPで書かれた簡単なRESTful APIと、Reactを使ったSPAの例を示します。

PHPによるRESTful API

PHPで簡単なAPIエンドポイントを作成します。この例では、GETリクエストを受け取り、簡単なJSONデータを返します。

<?php 
    header('Content-Type: application/json');
    $response = ['message' => 'Hello, world!'];
    echo json_encode($response); 

    // Response
    //{"message": "Hello, world!"} ?>

このPHPスクリプトは、サーバーに配置してのようにアクセスするとJSONが返されます。

ReactによるSPA

Reactで簡単なSPAを作成し、上記のAPIからデータを取得して表示します。

import React, { useState, useEffect } from 'react';
import axios from 'axios';

function App() {
  const [message, setMessage] = useState('');

  useEffect(() => {
    axios.get('http://yourserver.com/index.php')
      .then(response => {
        setMessage(response.data.message);
      })
      .catch(error => console.error('There was an error!', error));
  }, []);

  return (
    <div>
      <button>{message}</button>
    </div>
  );
}

export default App;

SPA（シングルページアプリケーション）とRESTful APIを使用する際には、セキュリティとパフォーマンスの両方に配慮することが重要です。
以下では、これらの観点から基本的なガイドラインをいくつか紹介します。

セキュリティ

1. HTTPSを使用する
   データの暗号化を確実に行うため、APIとの通信には常にHTTPSを使用します。（当たり前です）
   これにより、中間者攻撃（MITM）のリスクを減らすことができます。
2. CORSポリシーを適切に設定する
   クロスオリジンリソースシェアリング（CORS）ポリシーを適切に設定し、信頼できるオリジンからのリクエストのみを許可します。
   不適切なCORS設定は、セキュリティリスクを招く可能性があります。
3. 認証と認可
   JWT（JSON Web Tokens）やOAuthなどの堅牢な認証メカニズムを使用して、APIへのアクセスをセキュアに管理します。
   また、ユーザーの権限に基づいてアクセスを制御する認可も重要です。
4. 入力の検証とサニタイズ
    SQLインジェクションやクロスサイトスクリプティング（XSS）攻撃を防ぐため、サーバー側とクライアント側の両方で入力値の検証とサニタイズを行います。
5. 依存関係のセキュリティ
   使用するライブラリやフレームワークのセキュリティ脆弱性に注意し、定期的に更新を行い脆弱性を修正します。

この辺の対策については過去に記事にしていますので時間ある人は読んでみてくださーい

[getpost id=”1618″ cat_name=”1″ date=”0″][getpost id=”1256″ cat_name=”1″ date=”0″]

パフォーマンス

1. コードの分割
   ユーザーが必要とするコードのみをダウンロードするように、コード分割（Code Splitting）を実装します。
   これにより、初期ロード時間を短縮できます。
2. キャッシュ戦略の利用
   静的リソースやAPIレスポンスのキャッシュを適切に利用することで、パフォーマンスを向上させることができます。
   ブラウザのキャッシュやCDNの利用が有効です。
3. 遅延ローディング（Lazy Loading）
    画像やコンポーネントなど、必要になるまでロードしないようにします。
   これにより、初期ロードのパフォーマンスを向上させることができます。
4. APIの最適化
   不必要なデータの送受信を避けるため、APIのレスポンスをできるだけ小さく保ちます。
   また、必要なデータのみを取得するためのフィルタリングやページネーションをAPI側でサポートします。
5. フロントエンドのパフォーマンス最適化
   Reactなどのフロントエンドフレームワークを使用する場合は、不要な再レンダリングを避け、メモ化（memoization）や仮想DOMの効率的な利用などのテクニックを活用します。

セキュリティとパフォーマンスは、アプリケーションの設計と開発の初期段階から考慮する必要があります。
これらの基本的なガイドラインを実践することで、ユーザーに安全で快適な体験を提供することができます。

「これ、本当に〇〇さんから？」って疑っちゃう時があると思います。

そんな不安を解消してくれるのが、DMARCっていう技術。今日はこのDMARCについて、わかりやすく解説していこうと思います〜

DMARCってどんなもの？

DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、フィッシング詐欺やスプーフィング攻撃といったメールによるセキュリティ脅威からブランドを保護するための電子メール認証プロトコルです。

このプロトコルは、送信者のドメインがSPF（Sender Policy Framework）とDKIM（DomainKeys Identified Mail）による認証を経て、正当なものであるかどうかを受信者に確認させることで、不正なメールを効果的にフィルタリングします。

[getpost id=”1651″ cat_name=”1″ date=”0″]

DMARCの設定

DMARCを設定するには、まずSPFとDKIMが正しく設定されていることを確認する必要があります。

その後、DMARCレコードをドメインのDNSに追加します。
このレコードには、メールがSPFやDKIMの検証に失敗した場合の取扱い（例：報告のみ、隔離、拒否）、報告書の送付先、ポリシーの適用範囲などが記載されます。

DMARCの利点

DMARCの最大の利点は、フィッシングやスプーフィングによる攻撃からユーザーとブランドを守ることです。

また、送信者が自分のドメインを使用して送信されるメールをより詳細にコントロールできるようになり、送信メールの認証失敗に関するフィードバックを受け取ることができます。

これにより、メール配信の問題を迅速に特定し、解決することが可能になります。

DMARCの課題

DMARCの導入は、設定の複雑さや誤設定によるメール配信の問題が生じる可能性があるという課題を伴います。

特に、小規模な組織や技術的なリソースが限られている場合、DMARCの設定と維持が難しいことがあります。

また、DMARCでは全てのメール脅威を防ぐことはできないため、他のセキュリティ対策と併用することが推奨されます。

まとめ

DMARCは、メールによるセキュリティ脅威に対抗するための強力なツールです。

正しく設定されたDMARCポリシーは、不正なメールを効果的にフィルタリングし、受信者と送信者の信頼を高めることができます。

しかし、その設定と維持には注意が必要であり、導入にあたっては適切な知識とリソースが求められます。

DMARCを導入することで、メールを通じた安全な通信を行うことができまっす。

SPFは、メール送信者が使用しているドメイン名が正規のものであるかを検証するための技術です。つまり、あるドメインから送られてくるメールが、そのドメインの管理者によって認められたサーバーから送信されたものであることを確認する仕組みです。

SPFの設定は、ドメインのDNSレコードにSPFレコードを追加することで行います。
このレコードには、「このドメインからメールを送ることが許可されているIPアドレスは何か」という情報が含まれています。
メールを受け取ったサーバーは、この情報をもとに、メールが正規のサーバーから送られてきたものかを検証します。もし一致しなければ、そのメールはスパムやフィッシングの可能性が高いとみなされ、適切に処理されます。

SPFの設定方法

SPFの設定は、基本的にはドメインのDNS設定にSPFレコードを追加することで行います。以下は、SPFレコードの設定手順の概要です。

1. SPFレコードの作成：
   • SPFレコードは、v=spf1から始まります。これに続けて、メールを送信することが許可されているIPアドレスやドメイン、ポリシーを指定します。
   • 例えば、v=spf1 ip4:123.456.789.0/24 -allというレコードは、123.456.789.0/24からのメール送信を許可し、それ以外からの送信は拒否することを意味します。
2. DNSレコードへの追加：
   • ドメインの管理画面にログインし、DNS設定セクションを探します。
   • 新しいTXTレコードを作成し、先ほど作成したSPFレコードの値を入力します。
   • 設定を保存し、変更が適用されるのを待ちます（数時間かかることがあります）。

DKIM（DomainKeys Identified Mail）について

DKIMは、メールが送信途中で改ざんされていないことを確認するための技術です。
メールの送信者は、メールにデジタル署名を加えます。この署名は、送信者のドメインに関連付けられた公開鍵を使って検証することができます。公開鍵は、同じくドメインのDNSレコードに追加されます。

メールを受信した側は、この公開鍵を用いてデジタル署名を検証します。
もし署名が正しく検証できれば、メールは途中で改ざんされていないとみなされ、信頼性が高いと判断されます。このプロセスにより、メールの送信者が本当に主張しているドメインの管理者であること、そしてメール内容が改ざんされていないことが確認されます。

DKIMの設定方法

DKIMの設定は、少し複雑で、メールサーバーでの設定変更が含まれます。以下は、DKIMを設定する基本的なステップです。

1. DKIM鍵の生成：
   • DKIM公開鍵と秘密鍵のペアを生成します。この作業は、使用しているメールサーバーのソフトウェアによって異なります。多くの場合、メールサービスプロバイダーがこれをサポートしており、自動的に行われます。
2. 公開鍵をDNSレコードに追加：
   • 公開鍵をドメインのDNSレコードにTXTレコードとして追加します。これにより、メールを受信した側が、送信されたメールのDKIM署名を検証できるようになります。
   • レコード名は通常、default._domainkeyのような形式で、_domainkeyはDKIMの標準です。値は公開鍵です。
3. メールサーバーの設定：
   • メールを送信する際に、DKIM署名をメールに自動的に追加するよう、メールサーバーを設定します。これは、メールサーバーの設定ファイルで指定するか、メールサービスプロバイダーの指示に従います。

SPFとDKIMの併用

SPFとDKIMは、それぞれ異なるアプローチでメールセキュリティを向上させます。

SPFは送信者のドメインが正しいかを検証し、DKIMはメールの内容が改ざんされていないことを保証します。これら二つの技術を組み合わせることで、より強固なメールセキュリティ体制を築くことができます。

特に、フィッシング詐欺やスパムメールは巧妙化しているため、送信者の正当性を検証し、メールの内容が安全であることを確認することが非常に重要です。SPFとDKIMを適切に設定することで、これらの脅威からユーザーを守る助けとなります。

まとめ

SPFとDKIMは、メールの安全性を確保するための重要な技術です。これらを正しく理解し、適切に設定することで、フィッシングやスパムから自分自身や組織を守ることができます。今回の記事が、SPFとDKIMの基本を理解し、より安全なメール環境を構築するきっかけになれば幸いです。

両者の違いをわからないままノリで進めていくと大恥かくので先に学んでおく事をおすすめします。

UFW（Uncomplicated Firewall）とは

UFWは、Linuxベースのシステムでファイアウォールを設定するためのツールです。

UFWは、iptablesと呼ばれるより高度なファイアウォール設定を簡略化したもので、コマンドラインを通じて簡単に設定できます。

主な特徴は以下です

• ポートベースのファイアウォール設定をサポート
  • 特定のポートへのアクセスを制御
  • IPアドレス、サブネット、アプリケーションなどの設定が可能。
• シンプルな構文
  • ufwは非常に簡単な構文を持っており、コマンドラインで簡単に設定できる
  • ufwはシステム全体のファイアウォールとして機能する。
  • ネットワークトラフィックを制御するために使用される。
  • 特にWebアプリケーションのセキュリティには直接関係なし。

使用例

サーバーに対してセキュリティに関わる制限を設ける。

#HTTPS の port 開放 
sudo ufw allow 443

#MySQL の port 開放 
sudo ufw allow 3306

#sshの port 閉鎖 
sudo ufw deny 22

ufw にてポートの開閉を明示的に指示ができる。

WAF（Web Application Firewall）とは

WAFは、Webアプリケーションのセキュリティを強化するためのセキュリティツールです。

WAFは、Webトラフィックに対する特定のセキュリティルールを適用し、Webアプリケーション攻撃（例：SQLインジェクション、クロスサイトスクリプティングなど）から保護します。

主な特徴は以下です

• Webアプリケーションに対するトラフィックフィルタリング
  • WAFは、HTTPおよびHTTPSトラフィックを対象として、不正なリクエストや攻撃を検出し、遮断します。
  • パターンマッチング：WAFは特定の攻撃パターンや脆弱性に対する署名またはルールを使用して攻撃を検出します。
  • ロギングと監視：WAFは攻撃試行をログに記録し、セキュリティエンジニアがそれを監視および対応できるようにします。

WAFはWebサーバーとWebアプリケーションの間に配置され、攻撃をブロックしてWebアプリケーションを保護します。

WAFは販売されている

今回の勉強をするまでは、WAFの防御する内容が SQLインジェクションや XSS などであったため、自分で記述するプログラムにて防御するものだと思っていました。（自分で書くべきプログラムの総称と思っていた…

内容を深掘っていくとWAFはかなりの数が外反されており、運用を楽にするためにたくさんの企業が導入しているということがわかりました。

独自のルールを付加させる事のできるAWS WAF はその内勉強しないといけないなぁという印象です…

用途の異なるセキュリティツール

UFW（Uncomplicated Firewall）とWAF（Web Application Firewall）は、異なるセキュリティ関連のツールであり、異なる用途と機能を持っています。

簡単にまとめると以下のとおりですー。

• UFWはシステムのファイアウォール設定を簡単に行うためのツール
• WAFはWebアプリケーションのセキュリティを向上させるための特化したセキュリティツール

有効なメールアドレスかどうかを検証するために以下のような流れで処理を組むことはよくあると思います。

1. メールアドレス入力（ユーザー）
2. ランダムな文字列を入力されたメールアドレスに送信（システム）
3. 受け取ったランダムな文字列を入力（ユーザー）
4. ユーザーが入力した文字列を送信した文字列と一致するか判定（システム）
5. 4の検証が正常に通過したら1で入力されたメールアドレスを有効なアドレスとして登録

そうですよね。メールアドレスの検証は絶対必要ですよね。
上記の流れに間違いはないはずです。

レビューを貰うまで完璧な実装をしたと思い込んでいました。

何が良くないのか？

問題になったのは、1で実施するユーザーが入力したメールアドレスの検証です。

ユーザーが入力したメールアドレスの検証では、以下の検証を実施しなければいけません。

1. メールアドレス形式か
2. DBに登録されていないメールアドレスか
3. 必要であればその他バリデーション

僕が実装した内容で問題となったのは、2のDBに登録されていないメールアドレスです。

僕の実装内容では、DBに登録されているメールアドレスが入力されたら「既に登録済みのメールアドレスです」とバリデーションエラーを出力していました。

それって、バリデーションに引っかかったメールアドレスが既に使用されている誰かのメールアドレスだと世に発表してしまっている状況でした。

具体的に以下の事象を引き起こしてしまう問題です。

1. バリデーションに引っかかったメールアドレスを用いて総当たり攻撃に使用される（ログインなど）
2. バリデーションに引っかかったメールアドレスを自分が管理しているシステム以外で使用される

1に関しては試行回数に制限をかければ問題ないのですが、2に関しては僕らが出来ることは何一つ有りません。
だって、自分らが管理しいない場所で悪用されるからです。

ここで取得されたメールアドレスを悪意のある業者に売ったり、取得した悪意のある人がよからぬメールを送信することが出来ちゃいます。

なんて恐ろしい事態に陥ってしまうのでしょう。。

対策

対策は色々あると思いますが、僕が思いつくやつ挙げていきます。

• 「無効な値です。」というバリデーションエラーを出力
  • 既に使われている事を明記しない
  • 正確な対策ではない
• 認証メールに添付するエンドポイントを絶対に検証が通らないエンドポイントにする
  • ランダム文字列を入力するフォームに特定の条件のみアクセス可能とするなどが必要（ちょっと面倒）

他にもあるはずなので、各自のシステムに合わせて実装してください。

預かったデータは大切に

良かれと思って実装した内容がユーザーの個人情報を危険に晒してしまうことがあることを学べた貴重な経験でした。

やりがちなミスだと思うので、皆様もお気をつけください。

攻撃内容

WEBシステムのログイン後にセッションIDを盗み、ログイン者として該当のシステムを操作する「なりすまし行為」です。

システムで扱う内容にもよりますが、以下のことが可能です。

• 不正送金
• 不正購入

他人の運転免許(名義)で契約したり他人のパスポートで海外で悪さするなどが似ている犯罪になります。

そのため自分の情報は守りましょうね！というのが非常に大切になってきます。

対策

攻撃する人にセッションIDを推測されないことが鉄則です。

まず最初にやることは見える位置にセッションIDを配置しないでください。

• URLにセッションを含まない
• hiddenにセッション値を設定しない(やる人いないと思いますが、一応)

その上でなりすましを防ぐためにログイン後にセッションIDを書き換えましょう。

PHPの場合は組み込み関数のsession_regenerate_id();を使用します。

上記関数を使用することで使用しているセッションIDを書き換える事が可能です。ログイン処理の関数を作って最後にsession_regenerate_id()関数を記述すれば安全にセッションIDを管理できます。

echo session_id(); //①
session_regenerate_id(); //セッションID書き換え
echo session_id(); //②

また仕組み上、セッションIDはCookieに保存されるのでHTTPS通信にのみCookieを有効化するように設定します。

//Apacheでの設定方法
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

//php.iniでの設定方法
session.cookie_httponly = 1

はじめにApache2の設定ファイルについて理解しておきます。

WEB検索にてApacheのセキュリティ対策と検索するとApache導入後に自動生成される「/etc/apache2/apache2.conf」に定義してと書いてあります。

私のようにSSL化に伴い、設定ファイルを作成した場合は作成したファイルにセキュリティ対策を定義します。

/etc/apache2/sites-available/ドメイン名.conf

「/etc/apache2/apache2.conf」と「/etc/apache2/sites-available/ドメイン名.conf」の違いとしては、

• 全般的な設定は/etc/apache2/apache2.confに定義してね
• サイトごとの設定をしたい場合は作成した設定ファイルに定義してね

って感じになります。

基本的に1サーバー1ドメインって形になるので、自動生成ファイルに記述していくことになるかと思います。

エラーが出る場合

これから紹介する対策を設定ファイルに定義した際にエラーが出る場合は下記のコマンドを実行してくださーい。

Invalid command ‘Header’, perhaps misspelled or defined by a module not included in the server configuration

エラー内容

Apache内でHTTPヘッダーの操作が許可されていませんよー。という内容

対策

下記コマンドでHTTPヘッダの有効化。

sudo a2enmod headers

クリックジャギング

クリックジャギングとは

悪意のあるウェブページや広告をユーザーが踏むことで、意図しない操作を実行してしまう攻撃です。

具体的にはiframeタグやリンクなどを挿入し、既存のコンテンツの上に透過した悪意のあるコンテンツを重ねることで悪意のあるコードを実行させてしまう手法です。
ユーザーからすると通常のボタンを押しただけなのに個人情報が盗まれてしまうという事象が発生します。

対策

HTTPヘッダーによる対策を実施します。

X-Frame-Options とはブラウザが特定のタグを許可するかどうかの設定です。

• DENY：どのサイトからも埋め込まれないようにする。
• SAMEORIGIN：同じオリジン（同じドメイン・プロトコル・ポート番号）のサイトからのみ埋め込まれるようにする。
• ALLOW-FROM：特定のURLからのみ埋め込まれるようにする。
  ※今は非推奨らしい

個人的には複数のサーバー(ロードバランサー)等で運用することが多いと思うので、SAMEORIGINを設定するケースが多いと思いますー。

Apacheの場合は以下のファイルに追記します。

X-Frame-Options: DENY

HTMLページに設定する場合は以下のように設定します。
※WEBサーバーに設定するのが推奨とのこと。

<meta http-equiv="X-FRAME-OPTIONS" content="DENY" />

XSS

XSSとは

悪意のあるスクリプトを注入し、ユーザーのブラウザで実行させることで、クッキー情報やセッションIDなどの個人情報を盗んだり、偽のWebページを表示してユーザーの意図しない行為を実施することができます。

具体的にはGETパラーメーターに悪意のあるウェブページのリンクを入れたりすることで実現できます。

考え方

基本的にアプリケーション側で文字列のエスケープ処理やサニタイズ処理を実施します。

Apacheでの対策

XSSフィルター機能を設定します。

XSSフィルター機能とはブラウザの機能であり、ウェブページに含まれるリクエストパラーメーターやHTMLタグなどの入力値を検査し、悪意のあるスクリプトがあれば削除/エスケープするなどの対策を実施します。

Header set X-XSS-Protection "1; mode=block"

CSP

CSPとは

Webページに埋め込まれる外部リソースの取り扱いを制限することを指します。

対策

Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; object-src 'none'; frame-ancestors 'none'"

CSPの設定後に以下のエラーが出る方はドメインも含む形で ‘unsafe-eval’を設定してください。

ご自身のJSファイルが正規のものと判断させるために必要です。

Uncaught EvalError: Refused to evaluate a string as JavaScript because ‘unsafe-eval’ is not an allowed source of script in the following Content Security Policy directive: “script-src ‘self’ ‘unsafe-inline'”.

ただし、Eval関数は文字列をJSの構文として扱うことが出来るので、推奨されません。

#実行されちゃう
let alert = alert('aiueo');
eval( "alert")

そのため、他にも追加で対策してください。
追加の対策として以下が考えられます。(N重にすることである程度は担保できるはずです。)

• XSSフィルター(サーバー側)
• 入力データの検証(アプリケーション側)

DOS/Ddos

DOS/DDOS

システムに対して大量のリクエストを送ることで正常なリクエストを中止/失敗させサービスを正常に運用させなくする攻撃です。

対策

mod_evasiveというモジュールを使用します。

Linuxのディストリビューションやバージョンによって記載するファイルが異なります。

<IfModule mod_evasive20.c>
   DOSHashTableSize 3097
   DOSPageCount 10
   DOSSiteCount 50
   DOSPageInterval 1
   DOSSiteInterval 1
   DOSBlockingPeriod 10
   DOSLogDir "/var/log/mod_evasive"
   DOSEmailNotify admin@yourdomain.com
   DOSWhitelist 127.0.0.1
</IfModule>

画像の直リンク

直リンクされて困ること

案件によっては、画像やPDFなどに情報を詰め込んだデータを扱う事があると思います。(保険の明細や履歴書など)

そういったデータをバイナリ化してDBへ登録するのではなく、特定ディレクトリに保管する場合に関しては、そのディレクトリに直接アクセスされてしまうと個人情報が公開されてしまいます。

そのための対策ですよん。

対策

リファラを使って直アクセスの対策を実施。

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?ドメイン.com [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F,L]

一応、Apacheならではの.htaccessを使用したアクセス禁止方法もあります。

[getpost id=”1215″ cat_name=”1″ date=”0″]

バージョン情報の非表示

バージョンを表示することで対象のバージョンに合わせた攻撃を実施される/バージョンのセキュリティホールを見抜くなどの脅威があります。

サーバーにてコマンドを打てばバージョンを確認できるので、バージョンは非表示にしましょう。

Apacheのバージョン非表示

ServerTokens Prod

PHPのバージョン非表示

/etc/php/{PHPのバージョン}/apache2/php.iniを編集。

expose_php=off

簡単に言うとパスワード認証を通すために何回もidとpwを試してログイン認証を突破する攻撃手法です。

この攻撃手法は単純な実施方法ですが、定義しているパスワードが強力なものであっても時間とコンピュータリソースさえあれば攻撃者に突破される事が可能です。

昨今ではクラウドサーバーやレンタルサーバーなど誰でもサーバーを立ち上げやすくなっているので要注意です。

Ubuntuでの対策

サーバー側の設定です。

ブルートフォースアタックをさせないためにPWでのログインではなく鍵認証でのログインのみを有効にすることがベストな対策です。(むしろやらないと駄目です。)

Ubuntuでの対策はSSHファイルを編集します。

sudo nano /etc/ssh/sshd_config

ファイル内で以下の行をコメントアウト。
やりたいことはパスワードによるSSH接続を許可するかどうかを制御

#PasswordAuthentication yes

ファイル内で以下の行を追記。
やりたいことはパスワードが空の場合でもSSH接続を制御
※上記のPasswordAuthenticationで制御しているので必須ではない。むしろ不要かも。

PermitEmptyPasswords no

最後にsshサービスの再起動。

sudo systemctl restart sshd

Laravelでの対策

アプリケーション側での設定です。

Laravelでは、既存のファイルを編集することで対策可能です。

app/Http/Requests/Auth/LoginRequest.phpを編集。

ログイン回数の設定

tooManyAttemptsの引数：ログイン試行回数の設定

public function ensureIsNotRateLimited(): void
    {
        if (! RateLimiter::tooManyAttempts($this->throttleKey(), 5)) {
            return;
        }

        event(new Lockout($this));

        $seconds = RateLimiter::availableIn($this->throttleKey());

        throw ValidationException::withMessages([
            'email' => trans('auth.throttle', [
                'seconds' => $seconds,
                'minutes' => ceil($seconds / 60),
            ]),
        ]);
    }

ログイン停止時間の設定

RateLimiter::hitの引数：停止時間の設定
※秒数指定。10分なら600。

public function authenticate(): void
{
        if (! Auth::guard($guard)->attempt(
                [$credentials_key['id'] => $email, $credentials_key['pw'] => $password],
                $remenber)
            ) {
            RateLimiter::hit($this->throttleKey(),60);

            throw ValidationException::withMessages([
                'email' => trans('auth.failed'),
            ]);
        }
}

起こりうる脅威

■ 発生しうる脅威
SQL インジェクション攻撃により、発生しうる脅威は次のとおりです。
– データベースに蓄積された非公開情報の閲覧
個人情報の漏えい 等
– データベースに蓄積された情報の改ざん、消去
ウェブページの改ざん、パスワード変更、システム停止 等
– 認証回避による不正ログイン4
ログインした利用者に許可されている全ての操作を不正に行われる
– ストアドプロシージャ等を利用した OS コマンドの実行
システムの乗っ取り、他への攻撃の踏み台としての悪用 等

安全なウェブサイトの作り方 改訂第７版

ＰＨＰでの対策

プレースホルダ使おうね

フォーム入力がある値を直接SQL文に使用せず下記のようにバインド。

バインドは２パターンあるのですが、両方を一緒に使用することが出来ないので注意して下さい。

個人的には名前付きプレスホルダーで実装したほうがわかりやすいです。。。。

//疑問符パラメータ
$Stmt = $pdo->prepare('SELECT * FROM test WHERE id = ? and input_date = ?');

$Stmt->bindValue(1, '100');
$Stmt->bindValue(2, '2022-08-01');

$Stmt->execute();

//名前付きプレスホルダー
$Stmt = $pdo->prepare('SELECT * FROM test WHERE id = :id and input_date = :input_daet');

$Stmt->bindValue(':id', '100');
$Stmt->bindValue(':input_daet', '2022-08-01');

$Stmt->execute();

コマンドインジェクション

タグ内に悪意のあるコマンドを実行する内容を記述し、セキュリティ事故を起こす方法。

ｄｆ

起こりうる脅威

– サーバ内ファイルの閲覧、改ざん、削除
重要情報の漏えい、設定ファイルの改ざん 等
– 不正なシステム操作
意図しない OS のシャットダウン、ユーザアカウントの追加、変更 等
– 不正なプログラムのダウンロード、実行
ウイルス、ワーム、ボット等への感染、バックドアの設置 等
– 他のシステムへの攻撃の踏み台

安全なウェブサイトの作り方 改訂第７版

ＰＨＰでの対策