こんにちは！
ナビゲータのEVEです。
使用し始めたときの、MySQLは、レコードの1つの項目しかキーを設定できなかったので、困ることがなかったのですが、現在は、1レコードに複数のキーを設定でき、かつ、外部キーも設定できるので、いろいろな意味で悩みます。妄想をしてしまうのですが、Oracle同様に二次キーが使用できればこんなに悩むことがないのに、っと思ってしまいますが、何百万円もするデータベースとフリーのデータベースを一緒にしてはいけませんね・・・。
なんて、開発時の愚痴をいうのはこのぐらいにして、本日も具体的なセキュリティについて考えていきたいと思います。本日は、昨日も出てきたXSS攻撃についてです。
WAFの使用は、ゼロトラスト、セキュリティ・バイ・デザインの考えからすると、暫定的な対応となります。もし、システムを開発中なら、WAFの使用ありきではなく、自システムにセキュリティを実装することを考えるべきです。
ナビゲータのEVEです。
システム開発ですが、やっと、現時点考える、セキュリティを実現し、かつ、ログインするところまでこぎつけました。この時点で一番悩んでいるのが、テーブル設計・・・。最終正規化するのは当然なのですが、本日は、キーをどこまで含めるのか悩んでいました。キーを付ける目的としては、以下のような目的があります。
1)一意性の確保
2)データの整合性維持
3)検索・アクセスの高速化
4)データの管理・分類
5)セキュリティ・認証
6)データの更新・削除の効率化
7)データの重複防止
8)外部システムとの連携
9)ログやトランザクション管理
以上はChatGPTが列記してくれたものなのですが、私としては、1)一意性の確保、3)検索・アクセスの高速化を重要視しています。ただ、検索速度を早くしようとテーブル設計をしていると、キーとなる項目が増えてきます。ただ、その場合、1)一意性の確保が失われます。一意性を維持しながら、かつ、検索速度を早くしようと、テーブルをいろいろといじっていて、先ほどやっと落ち着き、今後の方針を決めました。ただ、できたてほやほやで、今後どうなるか分からないので、本日は、発言することは控えます。しかし、この場で発言し、仕様を確定したい気分です。そのぐらい悩みました。それと、今後仕様変更しようとした場合、かなり大変なのですよね・・・？2)データの整合性維持
3)検索・アクセスの高速化
4)データの管理・分類
5)セキュリティ・認証
6)データの更新・削除の効率化
7)データの重複防止
8)外部システムとの連携
9)ログやトランザクション管理
使用し始めたときの、MySQLは、レコードの1つの項目しかキーを設定できなかったので、困ることがなかったのですが、現在は、1レコードに複数のキーを設定でき、かつ、外部キーも設定できるので、いろいろな意味で悩みます。妄想をしてしまうのですが、Oracle同様に二次キーが使用できればこんなに悩むことがないのに、っと思ってしまいますが、何百万円もするデータベースとフリーのデータベースを一緒にしてはいけませんね・・・。
なんて、開発時の愚痴をいうのはこのぐらいにして、本日も具体的なセキュリティについて考えていきたいと思います。本日は、昨日も出てきたXSS攻撃についてです。
[XSS攻撃(クロスサイトスクリプティング:Cross-Site Scripting)]
■XSS攻撃とは？
XSSは、悪意のあるスクリプトをウェブサイトに埋め込み、訪問者のブラウザで実行させる攻撃手法です。
攻撃者は、ユーザーのセッション情報を盗んだり、不正な操作をさせたりすることができます。
★XSSの種類
❶反射型XSS（Reflected XSS）
・悪意のあるスクリプトを含むURLをユーザーにクリックさせ、サーバーからレスポンスとしてそのスクリプトを返す。
・ユーザーのブラウザでスクリプトが実行され、セッション情報の窃取などが可能になる。
・例: フィッシングサイトへの誘導、クッキーの盗難
❷持続型XSS（Stored XSS）
・悪意のあるスクリプトをサーバー側のデータベースや掲示板に保存し、他のユーザーがそのデータを表示した際にスクリプトが実行される。
・例: 掲示板やコメント欄に埋め込まれたスクリプトを通じた攻撃
❸DOMベースXSS（DOM-based XSS）
・JavaScriptの document.write() や innerHTML などを使って、不正なスクリプトをブラウザ側で動的に実行させる。
・例: クライアントサイドで不正な入力を処理し、実行してしまう
❹XSSの影響
・セッションハイジャック（クッキーを盗む）
・フィッシング詐欺
・マルウェアの配布
・ユーザーの個人情報の窃取
・ウェブサイトの改ざん
★XSSの対策方法
1)入力値の適切な処理
・エスケープ処理（サニタイズ）
・HTMLエンコード: & → &, < → <, > → > など
・JavaScriptエスケープ: \ を適切に処理
2)適切なコンテンツセキュリティポリシー（CSP）の導入
・Content-Security-Policy ヘッダーを設定し、スクリプトの実行を制限
3)HTTPOnly属性付きクッキーの使用
・HttpOnly を設定することで、JavaScriptからクッキーを取得できないようにする
4)JavaScriptの適切な利用
・innerHTML や document.write() の使用を避ける
・textContent や createElement() を使って安全に要素を追加
5)WAF（Web Application Firewall）の導入
・XSS攻撃を検知・ブロックするためのセキュリティ対策
■まとめ
・XSSは、ウェブアプリケーションにとって深刻な脆弱性の1つです。
・適切な対策を施し、安全な開発を心がけることが重要です。
この攻撃が騒がれてから久しく、対策を怠った場合、ひどい被害が想像されます。現在製造しているサイトも、当初から対策を考えていて、つい最近ブログの中で話しましたが、各インターフェースからデータが入ってきた場合、すべてのデータをhtmlspecialcharsでエスケープして、XXSの対策方法の1)を実現しています。2)については、つい先ほど、バーチャルホストのファイルに設定完了しました。HTTPOnlyについては、昨日設定完了しています。4)については、旧システムで利用している、innerHTMLをやめ、textContentを利用するようにします。XSSは、悪意のあるスクリプトをウェブサイトに埋め込み、訪問者のブラウザで実行させる攻撃手法です。
攻撃者は、ユーザーのセッション情報を盗んだり、不正な操作をさせたりすることができます。
★XSSの種類
❶反射型XSS（Reflected XSS）
・悪意のあるスクリプトを含むURLをユーザーにクリックさせ、サーバーからレスポンスとしてそのスクリプトを返す。
・ユーザーのブラウザでスクリプトが実行され、セッション情報の窃取などが可能になる。
・例: フィッシングサイトへの誘導、クッキーの盗難
❷持続型XSS（Stored XSS）
・悪意のあるスクリプトをサーバー側のデータベースや掲示板に保存し、他のユーザーがそのデータを表示した際にスクリプトが実行される。
・例: 掲示板やコメント欄に埋め込まれたスクリプトを通じた攻撃
❸DOMベースXSS（DOM-based XSS）
・JavaScriptの document.write() や innerHTML などを使って、不正なスクリプトをブラウザ側で動的に実行させる。
・例: クライアントサイドで不正な入力を処理し、実行してしまう
❹XSSの影響
・セッションハイジャック（クッキーを盗む）
・フィッシング詐欺
・マルウェアの配布
・ユーザーの個人情報の窃取
・ウェブサイトの改ざん
★XSSの対策方法
1)入力値の適切な処理
・エスケープ処理（サニタイズ）
・HTMLエンコード: & → &, < → <, > → > など
・JavaScriptエスケープ: \ を適切に処理
2)適切なコンテンツセキュリティポリシー（CSP）の導入
・Content-Security-Policy ヘッダーを設定し、スクリプトの実行を制限
3)HTTPOnly属性付きクッキーの使用
・HttpOnly を設定することで、JavaScriptからクッキーを取得できないようにする
4)JavaScriptの適切な利用
・innerHTML や document.write() の使用を避ける
・textContent や createElement() を使って安全に要素を追加
5)WAF（Web Application Firewall）の導入
・XSS攻撃を検知・ブロックするためのセキュリティ対策
■まとめ
・XSSは、ウェブアプリケーションにとって深刻な脆弱性の1つです。
・適切な対策を施し、安全な開発を心がけることが重要です。
WAFの使用は、ゼロトラスト、セキュリティ・バイ・デザインの考えからすると、暫定的な対応となります。もし、システムを開発中なら、WAFの使用ありきではなく、自システムにセキュリティを実装することを考えるべきです。
[あとがき]
今日と明日は、取り急ぎ作ったシステムでレギュレーション違反が散見されるので、その部分を修正し、明日の夕方ぐらいから、ログイン後の承認をするシステムの製造に入ります。
急ぐ気持はあるのですが、作ったモノがお粗末ではね・・・。現在しっかり作っておけば後で楽ができますし、フレームワーク製造後は、多くの人に利用していただきたいと考えています。そこから先は、著作権は放棄はしませんが、製造、改修については、何の制約をつけないつもりです。そのときお粗末なシステムでは、利用したいとは思わないでしょう？なんてことを考えながら、がんばっています。4月末に、αシステムへ公開できる範囲内で製造したものを公開しますので、ご意見をいだだければうれしいです。
では、また！
コメント
コメントを投稿