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

セキュリティ

WEBサイト構築

定期的なパスワード変更をなくす(上司を説得する)には

# パスワードは、肉やパンのように腐ったりしない
だから「消費期限」なども必要ない。

とは少々乱暴な意見かも知れませんが、これには裏付けがあって、
2017年米国国立標準技術研究所 (NIST) による刊行物の、パスワードのベスト・プラクティスに以下のように記載されています。

*認証コードの漏えいの証拠がある場合、または加入者から変更の要求があった場合を除き、
「検証者は、記憶された秘密情報を恣意的（定期的など）に変更することを要求してはならない」
また、「大文字や小文字を混ぜたパスワード」を推奨してきたが、これらも「無意味だった」*

としています。

Microsoft社でも、この刊行物に従って
Windows 10 v1903およびWindows Server v1903のセキュリティベースライン（DRAFT）において、**定期的なパスワード変更を必要とするパスワード有効期限ポリシーを削除する**とのこと。

Microsoft社は、なぜパスワードの有効期限ポリシーを削除するのですか？
という疑問に対して、
**パスワードが盗まれることがない場合は、期限切れにする必要はありま

AWSを触る　～アカウント登録と最低限のセキュリティ設定まで～

AWSでアカウントを作ってみたいと思います。
一応やりながら下に流れを書いていこうと思いますが、こちらに公式がありますので、これからやる人は公式を見たほうがいいと思いますので、参考にしてもらえればと思います。

[AWS アカウント作成の流れ](https://aws.amazon.com/jp/register-flow/)

#AWSのアカウント取得
googleで調べたらすぐ出てきますが、AWSのサイトへアクセスします。
[クラウドならアマゾン ウェブ サービス 【AWS 公式】](https://aws.amazon.com/jp/)
無料アカウント作成ボタンを押下します。

メールアドレスとパスワード、アカウント名を入力して「続行」ボタンを押下します。
（記載されているように12ヶ月は無料枠

OWASP ZAP で診断する OWASP Top 10 Project

[OWASP ZAP](https://www.zaproxy.org/) の公式ドキュメントに、ZAP を使った診断で [OWASP TOP 10](https://owasp.org/www-project-top-ten/) をカバーするためのガイドがあります。

– [ZAPping the OWASP Top 10](https://www.zaproxy.org/docs/guides/zapping-the-top-10/)

本記事ではこの [ZAPping the OWASP Top 10](https://www.zaproxy.org/docs/guides/zapping-the-top-10/) を参考に、OWASP Top 10 のセキュリティ要件を ZAP で診断するための様々なコンポーネントを紹介します。

OWASP や ZAP の概要については他の入門用の記事や[本家のドキュメント](https://www.zaproxy.org/)をご参照ください。
入門者の方には[脆弱性診断研究会](https://security-testing.doorke

Unityのモバイルゲーム向けクラッキングが行われるポイントを整理してみた

#免責事項

**この記事に記載されている内容を、実際に試して発生した損害に対していかなる責任も負いません（補償しません）。**
**すべて自己責任のもとで行ってください。**

リリースされているアプリやゲーム、[ソフトウェア利用許諾契約（EULA）](https://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E5%88%A9%E7%94%A8%E8%A8%B1%E8%AB%BE%E5%A5%91%E7%B4%84#%E3%83%AA%E3%83%90%E3%83%BC%E3%82%B9%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0)やアプリケーション利用規約などでリバースエンジニアリングは禁止されています。
実際に試す場合は、自分で開発しているアプリやゲームや脆弱性確認用でリリースされているアプリやゲームを使いましょう。

勘違いして理解しており、誤ったことを記載しているとこ

あやしいアクセス元の3分調査方法(初心者向け)

ふと怪しいアクセス元を見つけてしまったときに、どのくらい危険かをなんとなく3分くらいで調査する方法です。
本格的な調査の必要があるかどうかの判断材料の一つとして使えると思います。
なお、白の証明をするものではないので、ご注意ください。

## 役立つケース
* サイト運営をしていて、アクセス解析で極端に数の多いアクセスを見つけて、不安になってしまったとき
* Webサイトのアクセスログを確認すると、不審なリクエストが含まれていて、不安になってしまったとき

## 活用サイト
| サイト名 | 概要 | URL |
| —- | —- | —- |
| AbuseIPDB | 悪意のある活動(ポートスキャンや脆弱性スキャン等)に関連付けられたIPアドレスを報告、検索可能なサイト | https://www.abuseipdb.com/ |
| SANS Internet Storm Center | インターネット定点観測のデータを検索可能なサイト | https://isc.sans.edu/ |
| AlienVault – Open Threat Exchang

OpenVASによる脆弱性診断をDockerで手軽に実行する

Webセキュリティ入門本として有名な、`体系的に学ぶ 安全なwebアプリケーションの作り方(通称: 徳丸本)`を読んでいて、脆弱性診断ツールとしてOpenVASというものが紹介されていました。

個人的に開発しているWebアプリの脆弱性診断に試してみたいと思い色々調べていたら、専用のDocker Imageが公開されていたのでとても手軽に実行できました。

以下にやり方などまとめていきます。

# OpenVASとは
プラットフォーム脆弱性診断ツールです。
OSSなので無料で利用できます。

指定したホストをリモート（外部）からスキャンし、対象ホストのOS/ソフトウェアに既知の脆弱性がないかをチェックします。

診断の実行や診断結果の閲覧はCLIでも可能ですが、Webブラウザでのインターフェースも用意されているので今回はそちらを紹介してきます。

# 環境

OSX

“`
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.15.3
BuildVersion: 19D76
“`

Chrome

“`
$ osasc

iOSアプリケーションのリバースエンジニアリングガイドを作った

iOSアプリケーションのリバースエンジニアリングガイドを作ったので公開します。日本語です。書きかけです。

ARMアセンブリの読み方とかlldbの使い方に関しても書いてるので興味のある方はぜひ。

[iOS App RE Guide](https://4masaka.github.io/iOS-App-Reversing-guide/)

– [ARMアセンブリの読み方](https://4masaka.github.io/iOS-App-Reversing-guide/docs/side-content/arm-assembly)
– [lldbの使い方](https://4masaka.github.io/iOS-App-Reversing-guide/docs/side-content/lldb)
– [有用なツール集](https://4masaka.github.io/iOS-App-Reversing-guide/docs/side-content/useful-tools)

また、Githubで編集してるのでPRも募集してます。何卒……！
https://gi

AppGoat：その他の脆弱性

# エラーメッセージからの情報漏えい
エラーメッセージ出力を有効にしたままウェブサイトを運用することで、エラー発生時のメッセージからファイルやデータベースなど攻撃のきっかけとなる情報を提供してしまう問題、セキュリティ上の脆弱性。

## 脆弱性の原理
エラーメッセージをページ上に出力する際の設定に問題がある。
そのため、エラーが発生する入力を受けた際に公開するべきではない情報を提供してしまう。

## 脆弱性が悪用された際の影響
直接の影響はないが、ファイルやデータベースなどの情報が漏洩してしまい、別の手段による攻撃のきっかけとなりうる。

## 検査方法
エラーを出力するようなリクエストを送り、発生したエラーメッセージを確認する。
不正なURLの指定、想定しない入力などを行うとよい。
重要な情報がエラーメッセージを確認できる場合、脆弱性がある。

## 対策方法
エラー出力時の設定が問題なので、余計な情報を表示しないように設定するとよい。

– 実行環境設定によるエラー出力に関連する項目を無効化する。
– デバッグオプションによるデバッグ出力を無効化する。

# オープンリダイ

AppGoat：メールヘッダ・インジェクション

# メールヘッダ・インジェクションとは
メールヘッダを改ざんされ、送信先などの情報や本文を改ざんされうる脆弱性。

# 脆弱性の原理
メールを送信できるウェブアプリケーションの入力欄から改行を含む入力を受け、意図しない宛先や本文の改変を受け入れてしまうことで発生する。
入力受付時のチェックが甘いために発生する脆弱性である。

# 脆弱性が悪用された際の影響

– 意図しない宛先へのメール送信
– メール内容の改ざん
– メールの第三者中継

# 検査方法
メール送信機能を持つウェブアプリケーションのFROM欄などに、改行を含めた値を入れてリクエストを送信する。
このとき、メール本文の改ざんが見られる場合、脆弱性がある。

GET方式を採用している場合、URLのクエリストリングに入っているヘッダの情報も検査の対象となる。

# 対策方法
改行コードが入力されている場合、メールの送信を受け付けないようにする。

AppGoat：HTTPヘッダ・インジェクション

# HTTPヘッダ・インジェクションとは
悪意のあるレスポンス内容の書き換えによりHTTPレスポンスヘッダの出力処理で発生する脆弱性。
クロスサイト・スクリプティングと共通の影響がある。

# 脆弱性の原理
ユーザが入力可能な欄からのリクエストによってレスポンスヘッダの書き換えが行われることにより発生する。
URLの入力欄は対象になりやすい。

具体的には、改行コードを認識してしまうことにより、入力された内容ので悪意のある改変が可能となっている。

# 脆弱性が悪用された際の影響

クロスサイト・スクリプティングと共通の影響がある。

– 任意のCookie発行
– 表示内容改ざん（ニセのフォームの作成、JavaScriptを用いたCookieの盗難にもつながる）
– キャッシュサーバの汚染（ウェブページの改ざんとなり、サーバ側の被害が大きい）

# 対策方法
PHP5.4以降は改行コードを認識しないため、ヘッダの書き換えが発生しない。
そのため、新しいバージョンのPHPを利用することが対策となる。

それ以前のバージョンを使う場合、改行コードが異なるので実装の際は注意する必

AppGoat：クリック・ジャッキング

# クリック・ジャッキングとは
罠ページの上に正規のウェブサイトを透明にして重ねることで、正規サイト上でユーザの意図しない操作を誘発する攻撃、それを実装されうる脆弱性のことを指す。

# 脆弱性の原理
罠サイトのフレーム内に正規サイトを表示できることが原因。
攻撃者がユーザに罠ページのリンクを踏ませることで、ユーザのブラウザ上に偽装された罠ページが表示される。
正規サイトが透明な状態でレイヤーされているため、ユーザは意図していなくても正規サイトは正規なリクエストとして処理を行ってしまい、被害につながる。

# 脆弱性が悪用された際の影響
主にユーザがログインしていないと利用できないサービスが攻撃の対象となる。

– ログイン後のユーザのみが利用可能なサービスの悪用
– ログイン後のユーザのみが編集可能な設定の変更

# 検査方法

検査ツールから “`X-Frame-Options“` を確認し、“`ORIGIN“` か “`DENY“` になっていない場合は脆弱性が疑われる。
# 対策方法
他のサイトでフレーム内にウェブページを表示させないようにすることが対策となる。

AppGoat：認証制御や認可制御の欠落

# 認証制御や認可制御の欠落とは
認証制御の欠落とは、第三者が知りうる情報での認証、本来認証が必要なページから飛ぶべきページに認証無しで直接URL指定で移動することを許してしまう脆弱性である。
認可制御の欠落とは、権限の付与・管理が甘いことにより、ログインしているユーザが権限外のページにアクセスできてしまう脆弱性である。

# 脆弱性の原理
##### 認証制御の欠落
ログイン情報を用いたユーザの識別を、認証が必要なページで行っていない、行っていても不十分であることが原因。
その場合、認証無しで直接URL指定することで、認証無しで認証が必要なページにジャンプできてしまう。

そもそも認証に必要な情報が第三者が知りうる情報のみである場合、攻撃者による不正なログインを許してしまう。

##### 認可制御の欠落
アクセス権限の確認が不十分なことが原因で、アクセスに権限が必要なページでへと本来権限のないユーザがURL指定でジャンプできてしまう。

# 脆弱性が悪用された際の影響
共通して、本来非公開である情報に対して、攻撃者が閲覧、改ざん、消去してしまう危険性がある。

# 検査方法
##

AppGoat：バッファオーバーフロー

# バッファオーバーフローとは
外部からの入力の際、想定しない量の入力により、プログラムが用意したメモリ領域からデータが溢れて格納されてしまい、大事なデータの領域が上書きされてしまう脆弱性。

#脆弱性の原理
外部からの入力値を格納する際、本来プログラムが用意していたメモリ領域から溢れて格納することが主な原因である。
また、書き換えを受けた変数、その後の動作によっては更に被害が拡がる。
以下のを同時に満たすと条件を同時に満たすと攻撃が成功する。

1. プログラムの内部に侵入用の機械語コードを送り込むことができる。
2. 領域溢れによってジャンプ先のアドレスを書き換えることができる。
3. ジャンプアドレス先へプログラムの制御を移すことができる。
4. 侵入用コードを実行することができる。

# 脆弱性が悪用された際の影響
1. プログラムの異常終了
2. 外部から任意の機械コードの実行

サーバの場合、サービスの提供の中止につながる。
攻撃の内容や攻撃の対象によってはコンピュータの制御まで奪われかねない、大きな危険をはらむ脆弱性である。

# 検査方法
画面から入力できるパラメータ

AppGoat：SQLインジェクション

# SQLインジェクションとは
ウェブアプリケーションの中にはデータベースを操作する言語であるSQLを用いている場合がある。
攻撃者が不正なSQLのリクエストを送信することで、SQLによりデータベースの不正操作などをされてしまう脆弱性である。

# 脆弱性の原理
攻撃者がSQLの不正なリクエストを送信、サーバ側が実行できてしまうことが原因で脆弱性が存在している。
ウェブページ上の入力欄に加え、GET方式で送信している場合はURL中のクエリストリングも不正なリクエストの送信に用いられる。

攻撃の対象により2つに分類できる。

##### 文字列リテラルに対するSQLインジェクション
入力されたデータ中に不正なSQL文を構成する文字列が含まれており、不正な動作を起こしてしまう。

##### 数値リテラルに対するSQLインジェクション
文字列は異なりクォートしないため、文字列リテラルのエスケープ（後述）に相当する処理はない。

# 脆弱性が悪用された際の影響
この脆弱性を利用した攻撃では、サーバ側に不正な操作がされる。

1. データベースに蓄積された非公開情報の閲覧
2. データベー

AppGoat：クロスサイト・スプリクティング

# クロスサイト・スクリプティングとは
悪意のある人が不正なスクリプトをウェブページに埋め込み、利用者がブラウザ上で不正なスクリプトを実行してしまい被害にあってしまう脆弱性のことを言う。
その他の脆弱性と組み合わせて使われてしまうこともある。

#脆弱性の原理
悪意のある人が不正なスクリプトを何らかの形で埋め込み、第三者が不正なスクリプトを実行することにより発生する。
埋め込みの方法、形式によって3種類に分類される。

#####反射型クロスサイトスクリプティング

ウェブアプリケーションがユーザから受け取った入力をそのままの形でウェブページの出力に利用していることが原因で発生する。
ウェブページの入力欄や、GET方式を採用している場合のURL中のクエリストリングから攻撃されうる。

#####格納型クロスサイトスクリプティング

攻撃者が入力した不正なスクリプトを、ウェブアプリケーションが内部に格納してしまうことが原因で発生する。
この場合、不正なスクリプトを格納したウェブページにアクセスしたすべてのユーザが被害を被る可能性がある。

#####DOMベースのクロスサイトスクリプテ

AppGoat：CSRF

# CSRFとは
CSRF（シーサーフ）とはクロスサイト・リクエスト・フォージュリという脆弱性の略称である。
攻撃者が悪意のある罠を用意し利用者が踏んでしまうことで、利用者の意図しないリクエストが実行させられてしまう脆弱性である。
ログイン後に利用可能なサービスを攻撃者が悪用することにつながる。

# 脆弱性の原理
主に、リクエストをしたのが本来の利用者本人であるかの確認が甘いことに起因した脆弱性である。
以下の3つの要素を同時に満たす場合、脆弱性が存在する。

1. 本人認証のためのトークンをhidden属性で持っていない、あるいは推測が可能。
2. 重要な処理の際にパスワードの再入力を求めていない。
3. どこからのリクエストであるかを確認するRefererを確認していない。

# 脆弱性が悪用された際の影響
利用者がウェブアプリケーションにログインしている最中に罠を踏んでしまうことで、攻撃者に以下のような攻撃を許してしまう。

1. ログインしユーザのみが利用可能なサービスを悪用されてしまう。
2. ログインしたユーザのみが編集可能な情報を改ざんされる。

# 対策方法
原理の

AppGoat：OSコマンド・インジェクション

# OSコマンド・インジェクションとは
攻撃者のリクエストにより、不正なOSコマンドが実行されてしまう脆弱性である。

# 脆弱性の原理
ウェブページの入力欄やURLのクエリストリングなどに攻撃者がOSコマンドを含めることにより、意図しないOSコマンドを実行させることにつながる。
このとき、ウェブアプリケーション側がシェルに実行可能な形で入力を受け渡すことがOSコマンドの不正な実行に繋がっており、直接的な原因となっている。

# 脆弱性が悪用された際の影響
OSコマンド・インジェクションによるOSコマンドの実行はサーバ側に大きな影響があるばかりでなく、他システムへの攻撃にもつながってしまう。

1. サーバ内のファイルを不正に操作される。
2. 不正にシステムを操作される。
3. 不正なプログラムがダウンロード、実行される。
4. 他システムへの攻撃の踏み台にされる。

# 検査方法
ウェブアプリケーションの入力欄、URL中のクエリストリングにOSコマンドを入力し、実行されるかどうかを調べればいよい。
入力可能な欄に `&/windows/system32/ping -n 21 1

AppGoat：ディレクトリ・トラバーサル

# ディレクトリ・トラバーサルとは
ウェブアプリケーション上のファイル名を指定可能な機能を利用した場合、入力されたファイル名へのチェックが不十分だと非公開なファイルへのアクセスなどを許してしまう脆弱性。

# 脆弱性の原理
ウェブアプリケーションの入力欄、URL中のクエリストリングを用いた入力でファイル名を指定する場合、パスを書き換えることにより公開していない部分のファイルにアクセスすることで被害が発生しうる。
入力されたファイル名のチェックが不十分で、公開していない部分にパスを用いてアクセス可能なことが原因である。

# 脆弱性が悪用された際の影響
被害を受けるのはウェブサーバである。
悪用された際はサーバ内の非公開も含めたファイルの閲覧、改ざん、削除が起きうる。

# 対策方法
可能ならば外部の入力値で直接ファイル名を指定できないようにすることが有効。
リスト形式で選択したり、番号で指定するようにする方法などが考えられる。

外部からの入力が必要な際は、ファイル名にディレクトリ名が含まれないようにし、攻撃者によるパスの指定で非公開な部分にアクセスできないようにする必要がある。

AppGoat：セッション管理の不備

# セッション管理の不備とは
利用者のセッションIDを攻撃者が取得、利用することで、攻撃者が利用者になりすますことをセッションハイジャックと呼ぶ。
セッション管理の不備は、セッションハイジャックを許してしまう脆弱性である。

# 脆弱性の原理
Webサーバは基本的にクライアントを識別しないステートレスな状態だが、SNSやショッピングサイトをはじめ、個人を識別する必要のあるアプリケーションでは、個人の識別子を発行するセッションという動作を行う。
セッションIDはCookieを使用して各ユーザのブラウザに保存される。

本来、ログイン前後でセッションIDは推測困難なものを再発行するべきだが、不十分なセッションIDな管理だと攻撃者に利用される危険性がある。
攻撃者が他の利用者のセッションIDを利用する手段は以下の3種類となる。

##### セッションIDの漏洩
セッションIDをURLに埋め込んでいる場合、外部にセッションIDが漏洩してしまう可能性がある。
特に、情報を読み取るための罠のリンクを踏み悪意のある外部サイトに飛ばされ、Referer値を読み取られる危険性がある。
URLにセッシ