サーバーやアプリのセキュリティー

2022.04
クロスサイトスクリプティング (XSS)
クロスサイトリクエストフォージェリ (CSRF)
クロスオリジンリソース共有 (CORS) https://developer.mozilla.org/ja/docs/Web/HTTP/CORS https://qiita.com/att55/items/2154a8aad8bf1409db2b https://qiita.com/T_sa/items/7d5285b420698ea8ca15
SQLインジェクション
ディレクトリトラバーサル
Web Application Firewall (WAF)
『プロになるためのWeb技術入門』 ――なぜ，あなたはWebシステムを開発できないのか
(上のセキュリティの事についてもいくつか書いてある)
https://gihyo.jp/book/2010/978-4-7741-4235-7
クリックジャッキング (2025.01。FC2から対策通知きた)
https://help.fc2.com/web/manual/group4/4561
https://www.ipa.go.jp/security/vuln/websecurity/cl…
http://unixservermemo.web.fc2.com/sv/apache-mod-he…
\
ここまでは、大体以下の書籍に書いてあるので、読んで試してみる： (2025.05)
体系的に学ぶ安全なWebアプリケーションの作り方第2版 2018.6
https://www.sbcr.jp/product/4797393163/ https://wasbook.org/

１章 Webアプリケーションの脆弱性とは
２章 実習環境のセットアップ
 2.1 実習環境の概要
  Linux、nginx、Apache、PHP、Tomcat、MariaDB、Postfix
  (今回は仮想マシンではなく、Slack-15に直接Instして使おうと思ったが、Docker版の実習環境がある
   ようなので、そっちを使ってみる)
  DockerはこっちでInstした。https://shirakawa.weblike.jp/blog-page/2022/03/10...
 2.4 仮想マシンのインストールと動作確認 (2025.06)
  (ローカルで動かしているLAMP環境は、念のため止めておいた)
  $ sudo sh /etc/rc.d/rc.php-fpm-8.2 stop
  $ sudo sh /etc/rc.d/rc.postfix stop
  $ sudo sh /etc/rc.d/rc.mysqld stop
  $ sudo sh /etc/rc.d/rc.httpd stop
  (Docker上のマシンで設定する)
  $ sudo dockerd &
  $ docker run hello-world
  (動いてそうだ。が、docker compose up をやると巨大な領域をとるので、SSDの引越しが必要に。
   Dockerはnpmやphp_artisan以上に通信量もハンパないだろな〜。引っ越した そうでもなかった。
   Ubuntu辺りのベースシステムを持ってくるのかと思っていたが、Slackベースでも互換性ある?)
  $ unzip wasbook-docker.zip
  $ cd wasbook-docker
  $ docker compose up -d (または start。--project-directory wasbook-docker でdir指定)
  (動いてそうだ)
  $ docker container ls (または docker ps)
  (Dockerコマンドはこっちにまとめた https://shirakawa.weblike.jp/blog-page/2025/06/08... )
  (apacheコンテナが提供するPROXY(フォワードプロキシ) - 直接example.jpに接続しているわけではなく、
   http://127.0.0.1:13128（Apache Proxy）に接続し、そこからApacheが代わりに接続しています(->ChatGPT) 
   にFirefoxから接続して目次が表示できた。そこにFoxyProxyの設定方法もある)
  $ docker container --help (その他のhelp)
  $ docker compose stop (停止。dir移動した場合は元のdirに戻らないとコマンド効かない)
  $ docker compose start (再開)
  $ docker compose down (コンテナを停止 + 削除)
  $ docker compose down -v (ネットワークや未使用のボリュームも削除)
  $ docker compose down --rmi all (イメージも削除、関連イメージ含む)
  $ docker images (DLまたはInst済みイメージの確認)
 2.5 OWASP ZAP のインストール (2025.05)
  https://shirakawa.weblike.jp/blog-page/2025/05/19...
  $ export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
  $ export LD_LIBRARY_PATH=$JAVA_HOME/lib/server:$LD_LIBRARY_PATH
  $ export PATH=$PATH:/usr/lib/jvm/java-11-openjdk-amd64/bin
  $ cd ZAP_2.8.0; sh ./zap.sh &
 2.6 Firefoxの拡張FoxyProxy-Standardのインストール (2025.06)
  https://shirakawa.weblike.jp/blog-page/2025/06/01...
 2.7 OWASP ZAP を使ってみる
  (http://example.jpにFirefoxから接続して目次が表示でき、ZAPでhttp通信を確認できた)
 2.8 Webメールの確認
  (MailCatcherというWebメーラーを確認した)
３章 Webセキュリティの基礎
  ～ HTTP、セッション管理、同一オリジンポリシー、CORS
 3.1 HTTPとセッション管理
  https://www.php.net/manual/ja/features.http-auth.php
 3.2 受動的攻撃と同一オリジンポリシー
 3.3 CORS(Cross-Origin Resource Sharing )
  https://developer.mozilla.org/ja/docs/Web/API/XMLH...
  33-004a.php実行時のエラーメッセージ：クロスオリジン要求をブロックしました: 同一生成元ポリシー
  により、http://api.example.net/33/33-004a.php にあるリモートリソースの読み込みは拒否されます 
  (理由: CORS ヘッダー ‘Access-Control-Allow-Origin’ が足りない)。ステータスコード: 200は、
  CORS（Cross-Origin Resource Sharing）プリフライトリクエスト（OPTIONS）には適切なレスポンスが
  返ってきているが、本番のPOSTリクエストに対するレスポンスに**Access-Control-Allow-Origin ヘッ
  ダーが含まれていない**ため、ブラウザがCORSエラーとしてブロックしていることを意味しています。
  (->ChatGPT > DeepSeek)
  https://developer.mozilla.org/ja/docs/Web/HTTP/Gui...
４章 アプリケーションの機能別に見るセキュリティバグ (2025.07)
 4.1 Webアプリケーションの機能と脆弱性の対応
 4.2 入力処理とセキュリティ
 4.3 表示処理に伴う問題
 4.4 SQL呼び出しに伴う脆弱性 (2025.08)
  SQLのLIKE述語とワイルドカードの例 https://shirakawa.weblike.jp/blog-page/2024/08/18...
 4.5 「重要な処理」の際に混入する脆弱性
  罠の例：ログインしただけで残高消えるPayPay最恐詐欺 https://www.youtube.com/watch?v=ZMHlWzgKNeQ
  (そもそもQR決済はURLの確認を困難にしてしまうので使わない方がよい、と私は思う。またスマホは
   UIが貧弱でURLの確認が困難なので、買い物はPCでやった方がよいと思う)
 4.6 セッション管理の不備
  罠の例：Infostealer(情報窃取型マルウェア)について調べてみる 
  https://zenn.dev/banboobloom/articles/2025040300001
  (メンドクサイが、用が済んだらlogoutし寄り道しない、ブラウザには情報を持たせない)
 4.7 リダイレクト処理にまつわる脆弱性 (2025.09)
 4.8 クッキー出力にまつわる脆弱性
 4.9 メール送信の問題
 4.10 ファイルアクセスにまつわる問題
  結論（実質非公開ディレクトリを作りたい場合）(->ChatGPT)
   手軽に使いたいなら → Xserver / ConoHa / さくら
　  GUI でアクセス制御でき、初心者でも安心。
   コスト重視でとりあえず → Lolipop
　  .htaccess 手動設定で対応可。ただし設定ミスに注意。
   高セキュリティ・業務用途 → AWS
　  本格的な非公開構成を設計できるが、運用コストが高い。
 4.11 OSコマンド呼び出しの際に発生する脆弱性 (2025.10)
   アプリケーションの稼働するユーザ権限を最小にする -> 以降の「ECサイトのアカウント(オーナー)について」
    ディレクトリ・トラバーサル脆弱性などに対しても有効です。
 4.12 ファイルアップロードにまつわる問題
    .php以外のサーバースクリプト .asp .aspx .jsp .erb .py .js
    https://shirakawa.weblike.jp/blog-page/2025/10/11...
    @(エラー制御演算子)以外にもC言語にはない演算子 https://shirakawa.weblike.jp/blog-page/2025/10/12...
    $ grep pdf /etc/httpd/mime.types 
    application/pdf					pdf
    (他は省略)
    https://shirakawa.weblike.jp/blog-page/2022/03/15...
 4.13 インクルードにまつわる問題
    PHPのサポートするプロトコル/ラッパー、他にもある。
    https://www.php.net/manual/ja/wrappers.php.php
    https://www.php.net/manual/ja/wrappers.data.php
 4.14 構造化データの読み込みにまつわる問題
    eval()は文字列をスクリプトとして実行する関数、Bashでは関数ではなくコマンド形式
    $ php -r '$sum = eval("return 2+3;"); echo $sum."\n";' //5
    $ eval "echo Hello World" //Hello World
 4.15 共有資源やキャッシュに関する問題 (2025.11)
 4.16 Web API実装における脆弱性
    ・リファラーポリシー: クロスサイト要求について、制限の弱いリファラーポリシー “unsafe-url” を無視します: http://api.example.net/4g/4g-003.php?callback=display_time 4g-003.php
混在アクティブコンテンツ “http://api.example.net/4g/4g-003.php?callback=display_time” の読み込みをブロックしました。 4g-004.html https://developer.mozilla.org/ja/docs/Web/Security...
解除方法(->DeepSeek)
方法1: 警告アイコンから許可
アドレスバーの左側に表示されている盾のアイコンをクリック、「保護機能を無効にする」を選択、ページを再読み込み
方法2: 設定から完全に無効化（非推奨）
about:config、security.mixed_content.block_active_content を false に変更 (これしか効かない)
後から気付いたそもそも、http://example.jp/4h/4h-002.html の様に http: でスキームも含めて書かないと
自動で https: にされてしまう。
    ・4g-012.htmlのdone(func())について、前段の4g-011.phpからJSオブジェクトを引数で受けてfunc()を実行する、
で合っているか？ (->DeepSeek。ほぼ合っていますがより正確に説明)
done()メソッドの動作: $.ajax() が成功した場合（HTTPステータス200など）に実行される。サーバーからのレスポンスデータを引数として受け取る。レスポンスのデータタイプが dataType: "json" なので、PHPの json_encode() で出力されたJSON文字列が自動的にJavaScriptオブジェクトに変換されて渡される。
補足: done() はPromise形式の成功時コールバック。失敗時には fail() メソッドが実行される。常に実行したい処理は always() を使用する。
    ・trap.example.com/4g/4g-921.html を実行してもブラウザは4g-021.phpのPOSTで同じクッキーを出さないため、crack成功しない。Originを見ている?。(2025.12) XMLHttpRequest with withCredentials では、明示的なCORS設定がない限り、ターゲットドメインのクッキーは送信されません。これがブラウザセキュリティの重要な機能です。実際に成立するCSRF攻撃手法：フォームを使用したPOST送信。(DeepSeek) JSONではないため実際は失敗する。
https://www.php.net/manual/ja/function.file-get-c...、https://www.php.net/manual/ja/wrappers.php.php
    ・4g-022b.html $_SERVERの主なキー https://shirakawa.weblike.jp/blog-page/2022/03/24...
    ・http://trap.example.com/4g/4g-921b.html を実行しても403エラー。(->DeepSeek)
    1.プリフライトリクエストではセッションが開始されない？
    2.プリフライトリクエストでは$_SESSION['mail']が空？
    3.CORSヘッダーがないのでブラウザがブロック？
    ・JSのObjectオブジェクトは、https://shirakawa.weblike.jp/blog-page/2022/06/19を参照。
 4.17 JavaScriptの問題 (2026.01)
    ・JSのWindowオブジェクトは、https://shirakawa.weblike.jp/blog-page/2022/06/19を参照。
    ・JSのlocationオブジェクトは、https://shirakawa.weblike.jp/blog-page/2022/06/19を参照。
５章 代表的なセキュリティ機能 
 5.1 認証 (2026.02)
 5.2 アカウント管理
 5.3 認可
 5.4 ログ出力

参考情報：
2022.04
Webアプリケーションを作る前に知るべき10の脆弱性
https://atmarkit.itmedia.co.jp/ait/articles/0706/13…
https://atmarkit.itmedia.co.jp/ait/articles/0910/23…
https://www.pupha.net/archives/527/
https://www.mbsd.jp/blog/20161104.html
https://persol-tech-s.co.jp/corporate/security/art…
https://de-vraag.com/ja/55057251
Software Design 2022年2月号セキュリティキーITエンジニア流使いこなし術
https://gihyo.jp/magazine/SD/archive/2022/202202
JavaScriptでセキュアなコーディングをするために気をつけること
https://developer.cybozu.io/hc/ja/articles/201850320
安全なウェブサイトの作り方 – IPA
https://www.ipa.go.jp/security/vuln/websecurity/about.html
たまたま見つけた： 2022.12,2022.12,2025.06
Linux Foundation、ソフトウェアを安全に使用・開発する方法を無料で学べるオンラインコースを発表
https://codezine.jp/article/detail/16972
組込み Linux 向けセーフリスト型セキュリティソフト EMEliminator – サイバートラスト社
https://www.cybertrust.co.jp/iot/emeliminator.html…
EC-CUBE Penetration Testing with OWASP ZAP
https://doc4.ec-cube.net/penetration-testing
Webアプリセキュリティ対策【OWASP Top 10を実装で防ぐ】
https://www.youtube.com/watch?v=GxiprV8kMHY

/*************************************************************************************/
2024.09
ECサイトのアカウント(オーナー)について：
ECサイトをPHPで組むとして、DocumentRootを例えば、/www/myshop とした場合、myshop以下のファイルidはrootにすべきか？一般アカウントでもよいか？ (->ChatGPT)
どちらの回答がお好みですか？
お客様の選択は ChatGPT の改善に役立てられます。

回答１：
DocumentRoot 配下のファイルの所有者やグループに関して、一般的なセキュリティの観点からは、root アカウントが所有者になるべきではありません。むしろ、次のような設定が推奨されます。
1.ファイル所有者: DocumentRoot 以下のファイルは、Apache やウェブサーバーが実行されているユーザー（たとえば、www-data や apache）または、PHP のスクリプトをメンテナンスする開発者アカウントが所有者であるべきです。これは、root で所有すると、誤ってファイルを操作するリスクを減らすためです。
2.ファイルのパーミッション: ファイルのパーミッションも適切に設定する必要があります。PHP ファイルに関しては、読み込み権限だけが必要な場合が多く、一般的には次のような設定が安全です。
・ディレクトリ：755
・ファイル：644
理由:
・root で所有する場合、セキュリティのリスクが増加します。例えば、万が一、サーバーに脆弱性があった場合、攻撃者が root 権限を取得しやすくなります。
・一般ユーザーがファイルの所有者であれば、ウェブサーバーが過剰な権限を持たず、セキュリティ上より安全です。
そのため、一般アカウントやウェブサーバー用の専用ユーザーがファイルの所有者であることが推奨されます。

回答２：
ECサイトをPHPで構築する際のファイルおよびディレクトリの所有権（ファイルID）について、セキュリティと運用の観点から適切な設定を行うことが非常に重要です。以下に推奨される設定とその理由を説明します。
1. ファイルの所有者はrootにしない
・理由: rootユーザーはシステム全体に対する管理権限を持っており、Webサーバーがroot権限で動作すると、脆弱性が悪用された際にシステム全体が危険にさらされる可能性があります。したがって、Webコンテンツの所有者をrootにすることはセキュリティ上非常にリスクが高く推奨されません。
2. 専用の一般ユーザーアカウントを使用
・推奨方法:
・デプロイユーザー: サイトのファイルを管理するための専用のユーザー（例: deploy, myshopuserなど）を作成します。このユーザーが/www/myshop以下のファイルおよびディレクトリの所有者となります。
・Webサーバーユーザー: ApacheなどのWebサーバーが動作するユーザー（例: www-data, apache, httpdなど）と適切なファイル権限を設定します。
・設定例:
# 専用ユーザーの作成
$ sudo adduser myshopuser
# ファイルの所有権を専用ユーザーに変更
$ sudo chown -R myshopuser:www-data /www/myshop
# ディレクトリのパーミッション設定（755）
$ sudo find /www/myshop -type d -exec chmod 755 {} \;
# ファイルのパーミッション設定（644）
$ sudo find /www/myshop -type f -exec chmod 644 {} \;
# 必要なディレクトリに書き込み権限を付与（例: uploads, cache）
$ sudo chmod -R 775 /www/myshop/uploads
$ sudo chmod -R 775 /www/myshop/cache
3. パーミッションの設定
・ディレクトリ: 755（所有者が読み書き実行、グループとその他が読み実行）
・ファイル: 644（所有者が読み書き、グループとその他が読み取り）
・書き込みが必要なディレクトリ: 775または750（セキュリティ要件に応じて調整）
4. Webサーバーの権限を最小限に
・Webサーバーが必要以上の権限を持たないようにし、必要なファイルやディレクトリにのみアクセスできるようにします。
・PHPがファイルの読み書きが必要な場合でも、最小限の権限を付与します。
5. 追加のセキュリティ対策
・ファイルの所有権を分離: 可能であれば、Webコンテンツとアプリケーションの実行ユーザーを分離し、不要なアクセスを防ぎます。
・定期的なパーミッションの確認: ファイルやディレクトリの権限が意図しない変更を受けていないか定期的にチェックします。
・セキュリティモジュールの利用: Apacheのmod_securityなどのセキュリティモジュールを活用して、攻撃からサイトを保護します。
まとめ
・所有者をrootにしない: セキュリティリスクが高いため避ける。
・専用の一般ユーザーアカウントを使用: ファイル管理とWebサーバーの権限を適切に分離する。
・適切なパーミッションを設定: 最小限の権限で運用し、不要なアクセスを防ぐ。
これらの設定により、ECサイトのセキュリティを強化し、運用上の安全性を確保することができます。具体的なサーバー環境や要件に応じて、さらに詳細な設定やセキュリティ対策を検討することをお勧めします。
参考情報:
・Apache Official Documentation – File Permissions
・OWASP – Secure File Permissions
必要に応じて、具体的なサーバー環境や使用しているホスティングサービスに基づいた設定を行ってください。
注意: セキュリティ設定はシステム全体の安全性に直結しますので、不明点がある場合は専門家に相談することをお勧めします。
補足: 質問が日本語であったため、回答も日本語で提供しました。追加の質問や詳細な説明が必要な場合は、遠慮なくお知らせください。

参考：
アプリソフト、システムソフト、のオーナーについて
https://shirakawa.weblike.jp/blog-page/2025/06/01… (Firefoxでaddonができない件)
https://shirakawa.weblike.jp/blog-page/2025/06/03…
個人用アプリは何処に置くか
https://shirakawa.weblike.jp/blog-page/2025/06/02…

/*************************************************************************************/
侵入されていないかチェックする方法は？
Linux マシンが侵入されたかをチェックする方法には、「明確な痕跡（Indicators of Compromise）を探すこと」が中心になります。以下に、順を追って基本から実践的なチェック方法までご紹介します。 (->ChatGPT)
## ✅ 1.ログを確認する
### 🔍 ログイン履歴を確認
$ last
* 異常な時間帯のログイン
* 不明なIPアドレスからのログイン
### 🔍 失敗したログインを確認
$ grep ‘Failed password’ /var/log/auth.log
（CentOS系なら `/var/log/secure`）
* ブルートフォース攻撃があるとここに大量に出ます
## ✅ 2.不審なユーザー・グループの確認
### 🔍 root権限を持つユーザー一覧
$ awk -F: ‘$3 == 0 { print $1 }’ /etc/passwd
* 通常は `root` だけのはず
→ 見知らぬ名前があれば要注意。
### 🔍 全ユーザー確認
$ cut -d: -f1 /etc/passwd
* 見覚えのないユーザーがないか確認
## ✅ 3.SSHの設定とアクセス履歴
### 🔍 `.ssh/authorized_keys` が改ざんされていないか
$ cat ~/.ssh/authorized_keys
* 自分の公開鍵以外があればアウト
## ✅ 4.cron にバックドアが仕掛けられていないか
### 🔍 自分のcronジョブ
$ crontab -l
### 🔍 全体のcronスケジュール
$ ls -al /etc/cron*
* 怪しいスクリプト実行などが仕込まれていないか確認
## ✅ 5.プロセスとポートを監視する
### 🔍 不審なプロセス
$ ps aux | grep -vE ‘firefox|bash|gnome|systemd|ssh’
* `minerd`, `kworker`, `python3 -m http.server` など不審なものがないか
### 🔍 使用中ポートと接続
$ sudo netstat -tulnp
または：
$ sudo ss -tulnp
* 自分が開けていないポートが Listen 状態なら要注意
* `PID/Program name` を確認
## ✅ 6.rootkit 検出ツールの使用
### 🛠 `rkhunter`（rootkit検出）
$ sudo apt install rkhunter # または yum install rkhunter
$ sudo rkhunter –update
$ sudo rkhunter –check
### 🛠 `chkrootkit`
$ sudo apt install chkrootkit
$ sudo chkrootkit
## ✅ 7.最近変更されたファイルの調査
### 🔍 直近で変更されたファイルを確認（過去2日間）
$ sudo find / -mtime -2 -type f 2>/dev/null
* `/bin`, `/etc`, `/usr/bin`, `/usr/local/bin`, `/root` などの変更は要注意。
## ✅ 8.システムに不正な通信がないか確認
### 🔍 外部と通信しているプロセス
$ sudo lsof -i -n -P
* 不明なドメインやIPアドレスと通信しているプロセスがないか確認。
## ✅ 9.ファイルに異常なSUIDビットがついていないか
$ find / -type f -perm -4000 -ls 2>/dev/null
* `SUID`は特権昇格に使われる。
* 本来あるべきでない場所にあるなら要警戒。
## ✅ 10.パッケージの改ざん確認（Debian系限定）
$ debsums -s
* 改ざんされたバイナリがないかチェックします。

## 💡 結論とアクション
| 状況                               | 対応                                                       |
| ---------------------------------- | ---------------------------------------------------------- |
| 明らかに不審なアカウントやプロセス | 直ちにネットワーク遮断・ログバックアップ                   |
| 不審ログイン・通信                 | パスワード・SSH鍵の即時変更、再構築検討                    |
| 被害が断定できない                 | `rkhunter`, `chkrootkit`、バックアップ＆再インストール検討 |

## 🛡️ さらにやりたい方へ
* auditd：ファイル監視やコマンドの履歴を記録
* OSSEC：ホスト型IDS（侵入検知システム）
* fail2ban：SSHブルートフォース対策
必要であれば、「簡易チェック用スクリプト」を作成してお渡しすることもできます。希望があればお知らせください。

参考：
アカウントのチェック
https://shirakawa.weblike.jp/blog-page/2025/06/03…

/*************************************************************************************/

参考URL：
OpenSSL、GnuPG、GnuTLS
https://shirakawa.weblike.jp/blog-page/2022/03/13…
Apacheの設定
https://shirakawa.weblike.jp/blog-page/2022/03/15…
JVN JP Vendor Status Note
https://jvn.jp/nav/jvn.html

Slackware-15.0 メモ

サーバーやアプリのセキュリティー

コメントを残すコメントをキャンセル

最近の投稿

最近のコメント

アーカイブ

カテゴリー

Slackware-15.0 メモ

サーバーやアプリのセキュリティー

コメントを残す コメントをキャンセル

最近の投稿

最近のコメント

アーカイブ

カテゴリー

コメントを残すコメントをキャンセル