フォートノックスのように安全：ハッカーからウェブサイトを保護する方法

公開: 2021-10-05

この記事では、Webサイトがハッキングされて違法行為に使用されるのを防ぐ方法についてのガイドを提供します。

オンラインの安全性は、インターネットの無限の青空に浮かぶ大きな危険信号です。「オンラインの安全性」という言葉は、ユーザーに対するオンラインでの嫌がらせや保護を最初に思い起こさせるかもしれませんが、Webサイトのセキュリティの欠如がビジネスに与える可能性のある損害も重大です。セキュリティへの支出を削減したウェブサイトの所有者は、評判に応じて支払いを行い、その結果、経済的損失を被ります。

コンテンツ：

すべてのウェブサイトの所有者がセキュリティに投資する必要がある理由
私たちが話している脆弱性は何ですか？
注入の欠陥
機密データの公開
クロスサイトスクリプティング（XSS）攻撃
壊れた認証
セキュリティの設定ミス
壊れたアクセス制御
安全でない逆シリアル化
不十分なロギングとモニタリング
XML外部エンティティ（XXE）
既知の脆弱性を持つコンポーネントの使用
安全なウェブサイトを作成する方法
ウェブサイトを保護するのにどれくらいの費用がかかりますか？

すべてのウェブサイトの所有者がセキュリティに投資する必要がある理由

ウェブサイトのセキュリティに投資する

一部のウェブサイトの所有者は、次のような考えを持っています。私のウェブサイトで盗むものは何もありません。 ユーザーデータや支払いの詳細は保持していません。 高価な最高のセキュリティは必要ありません。

しかし、それは単純なナイーブです。個人データや財務データがホストされていなくても、Webサイトがハッキングされる理由はいくつかあります。これは、ハッカーが保護されていないサーバーに対して使用する可能性のある用途のリストです。

身代金を要求する。サーバーにユーザーデータを保持していなくても、ハッカーがそれらを乗っ取って、それらを取り戻すためにあなたにお金を要求する可能性があります。
SMTP（簡易メール転送プロトコル）リレーとして使用します。 SMTPは、ニュースレターなどの電子メールをまとめて配信するために使用されるプロトコルです。ハッカーはサーバーを使用してスパムやランサムウェアを送信できます。
ビットコインをマイニングします。
ボットネットの一部としてDDoS攻撃で使用するため。
ウェブサイト上のデータを変更または削除するため。そうする理由は異なる場合があります。

そして、それは表面を引っ掻いているだけです。サードパーティ（ハッカーやその他の犯罪者）による脅威のほかに、たとえば、Webサイトを管理している従業員のミスの可能性による脅威もあります。実際、内部のセキュリティは外部と同じくらい重要ですが、それ以上ではありません。

では、どうすれば自分のWebサイトをハッカーから保護できますか？ あなたが尋ねる。

さて、あなたは多くの脆弱性を説明し、対処しなければなりません。

私たちが話している脆弱性は何ですか？

サイバーセキュリティに関心を持つ業界で最も評判の良いエンティティの1つは、Open Web Application Security Project（略してOWASP）です。 OWASP Foundationは、広範囲にわたるWebセキュリティ問題のリストを監視し、定期的に更新します。以下は、この記事を書いた時点でのリストにある一般的なセキュリティの問題（順不同）と、Webサイトへの危険を減らすためのヒントです。

注入の欠陥

インジェクションの欠陥はデータベースに関係し、不十分な入力検証によって引き起こされます。システムがユーザー入力を受け入れても、その入力を適切にフィルタリングできない場合、システムは脆弱になります。ハッカーはこれを悪用して、システムにコードを挿入する可能性があります（そのため名前が付けられています）。この挿入されたコードにより、Webサイトが意図しないコマンドを実行し、機密データを表示したり、Webサイトの制御をハッカーに譲ったりする可能性があります。

最も一般的なタイプのインジェクションの脆弱性にはSQLデータベースが含まれますが、インジェクションの脆弱性は実際にはそれらに限定されません。 XPathクエリ、LDAPステートメント、およびXMLスクリプトも、インジェクションに対して脆弱である可能性があります。

Webサイトを注入の欠陥から保護するにはどうすればよいですか？ベストプラクティスの2つには、SQLクエリのサニタイズとパラメータ化されたクエリの使用が含まれます。それを可能にするAPIがあります。

これらを手動で実装したくない場合は、好みのプログラミング言語にORM（オブジェクトリレーショナルマッピング）ツールを使用できます。 Railsエコシステムと緊密にリンクされているため、ActiveRecordを使用します。

上記のオプションはどれも完全に確実なものではありませんが、最近では確実に保護されています。

機密データの公開

機密データとは、何らかの方法で人を悪用するために使用できるデータです。

名前
社会保障番号
運転免許証番号
クレジットカード情報
ユーザー名とパスワード
生年月日
健康情報
旧姓
両親の名前

銀行口座など、セキュリティの質問への回答となる情報を含めることもできます。あなたの最初のペットの名前が機密データと見なされる可能性があると誰が考えたでしょうか？

機密データの露出からWebサイトを保護することは困難です。これは、この露出を予測して検出することが難しいためです。しかし、あなたが取ることができる予防策があります。 機密データをWebサイトに保存する場合は、プレーンテキストとして保存しないでください。 最新のテクノロジーで暗号化し、安全なチャネルを介してのみ送信する必要があります。

Webサイトがトランザクションを容易にする場合、または一般的に機密データを扱う場合は、SSL暗号化を使用する必要があります。これは、利用可能な最新かつ最高の暗号化技術です。 SSL暗号化は、ブラウザとサーバー間、またはサーバー間でデータを安全に転送するのに役立ちます。さらに、多くのユーザーは、WebサイトのアドレスでHTTPSを探して、安全かどうかを確認します。そのヘッダーは、SSL証明書を取得したときに取得するものです。

また、一般的にデータをクラウドに保存することをお勧めします。ただし、クラウドに保存するだけで自動的にデータが安全になるとは限りません。それでも、すべての保護対策を実施する必要があり、セキュリティを定期的に監視および更新する必要があります。

クロスサイトスクリプティング（XSS）攻撃

XSSの脆弱性は、ハッカーが非ネイティブコードを挿入することで、Webサイトのページに影響を与える可能性があるため、ある意味で挿入の欠陥に似ています。 XSSの場合、JavaScriptインジェクションについて話します。ハッカーによって挿入されたJavaScriptは、ページコンテンツを変更したり、悪意のあるWebサイトへのリンクを挿入したり、元々隠されていたデータをハッカーに送り返したりする可能性があり、機密データが漏洩する可能性があります。

Ruby on RailsとReactには、XSS保護が組み込まれています。 XSS対策およびインジェクション対策の別のオプションは、Content-Security-PolicyHTTP応答ヘッダーを使用することです。

壊れた認証

壊れた認証フロー

もともと「壊れた認証とセッション管理」と呼ばれていたこの欠陥は、名前から明らかなように、ユーザー認証とセッション管理中の脆弱性を扱います。これには、ログイン資格情報の公開とセッションIDに関するいくつかの問題が含まれます。

弱いセッションID
URLに表示されるセッションID
ログイン間で変更されないセッションID
保護されていない接続を介したセッションIDの送信

セッションIDは、資格情報と同じようにユーザーのIDに直接接続されているため、セッションIDを傍受すると、ユーザーのアカウントが乗っ取られる可能性があります。これは、経済的および評判から健康関連に至るまで、ユーザーにあらゆる種類の損害をもたらします。

Webサイトを認証攻撃から安全にするには、多要素認証を要求します。たとえば、ユーザーのモバイルデバイスに配信される一定のパスワードとワンタイムパスワードを要求します。

Googleは2要素認証のオプションを採用しています。ウェブブラウザでGoogleアカウントを開くには、最初にパスワードを入力する必要があります。 正しければ、携帯電話でGoogleアプリを開き、ウェブブラウザに表示されている番号を選択する必要もあります。

壊れた認証のためのより明白なウェブサイト保護方法は次のとおりです。

パスワードの複雑さの強化—「パスワードは少なくとも8文字の長さで、少なくとも1つの数字、1つの大文字、および1つの小文字を含める必要があります。」
アカウントが一時停止される前（特定の時間またはユーザーがサイト管理者に連絡するまで）のログイン試行を制限し、管理者に警告する

セキュリティの設定ミス

これは、データベース、ネットワーク、サーバー、フレームワーク、ストレージなど、Webサイトのどの段階でも、どの部分でも発生する可能性があるため、セキュリティの設定ミスは幅広いトピックです。構成の弱点を悪用して、システム機能にアクセスすることができます。脆弱性がどこにあるかに応じて、そのようなアクセスは部分的または完全な場合があります。設定ミスの例：

デフォルトのアカウント/パスワードを無効にしていません。
不要な未使用の機能があります。
クラウドへのアクセス許可が安全に構成されていません。
エラーメッセージには、ユーザー名、パスワード、電子メールアドレスなどの機密情報が表示されます。

構成ミスを回避するために最初に行うことは、機能、サンプル、フレームワークなど、未使用のものをすべて削除することです。次のステップは、すべての環境で同じ構成を確保し、そのパフォーマンスを定期的にチェックすることです。よく考えられたアーキテクチャは必須です。

壊れたアクセス制御

アクセス制御とは、ユーザーが実行できることと実行できないことを制御することです。適切に実施されていない場合、ユーザーは予測できない方法でWebサイトに影響を与える可能性のあるアクションを実行できることを意味します。壊れたアクセス制御を悪用する1つの方法は、他のユーザーのプロファイルとデータを表示および編集することです。もう1つは、プレミアム機能にお金を払ったり稼いだりせずにアクセスすることです。さらにもう1つは、管理者以外のアカウントから（または、さらに悪いことに、アカウントなしで）管理者ページにアクセスすることです。

Webサイトのアクセス制御が機能していることを確認する最良の方法は、手動テストです。自動化されたテストツールは、アクセス制御が意図したとおりに機能することを保証できません。

アクセス制御が壊れているのは、クロスオリジンリソースシェアリング（CORS）メカニズムを悪用した結果である可能性もあります。これにより、制限されているAPIへのアクセスが提供される可能性があります。このため、CORSの使用はできるだけ少なくすることをお勧めします。

安全でない逆シリアル化

シリアル化は、オブジェクトをバイナリコードに変換するプロセスです。論理的には、逆シリアル化は逆です。どちらもWeb開発で定期的に行われるプロセスであるため、攻撃に使用されないように保護することが重要です。

良いニュースは、逆シリアル化は通常のユーザーや従業員が誤って行うことができることではないということです。 これは、部分的には悪いニュースでもあります。逆シリアル化攻撃は常に意図的なものであり、したがって悪質です。また、リモートコードの実行、認証なしでのWebサイトへのアクセス、DoS（サービス拒否）攻撃の開始など、最も深刻な問題が発生します。
このタイプの攻撃からWebサイトを保護する最も簡単な方法は、ユーザーが生成したシリアル化されたオブジェクトを禁止することです。これができない場合、次善の策は、整合性チェックに暗号署名を使用することです。

JSON、YAML、またはXMLを使用すると、これらの形式はバイナリではないため、ハッカーにとってデシリアライズの弱点を悪用することが難しくなる可能性があります。

不十分なロギングとモニタリング

この脆弱性は非常に明白なようです。Webサイトを監視せず、すべてのエラーをログに記録せず、ログインまたはアクセス制御機能の実行に失敗した場合、基本的にハッカーがWebサイトを攻撃するように誘惑します。デジタルであれ現実であれ、あらゆる種類の戦争において、最初の攻撃は通常、勝つことではなく、あなたが何に反対しているのかを見ることです。そして、簡単な方法があれば、それを使用します。このようなプロービングのログ記録と監視に失敗すると、システムが攻撃を完全に見逃したり、攻撃がすでに行われて損傷が発生した後にそれを検出したりすることになります。

ロギングは、ユーザーのお金と金銭的資格を扱うため、eコマースサイトにとって特に重要です。

Webサイトをより安全にするには、失敗したすべての試行を適切にログに記録し、これらのログがローカルサーバーの外部に保存およびバックアップされていることを確認します。そのような障害に対して自動アラートシステムを採用し、可能であれば、そのような障害を継続的に生成するアカウントを一時停止します。違反の可能性に即座に対応できるように、リアルタイムのアラートシステムを用意することが重要です。

XML外部エンティティ（XXE）

XML（Extensible Markup Language）についてはすでに数回言及しました。これは柔軟な言語であるため、使いやすく、広く普及しています。 XMLプロセッサは、XMLドキュメントからデータを解析します。 WebサイトがXMLベースであり、検証なしでXMLアップロードを受け入れる場合、攻撃を受けやすい可能性があります。

Webサイトの整合性を保護するために、次の一連のアクションをお勧めします。

DTD（文書型定義）処理を無効にします。
XMLアップロードを制限または防止するか、それができない場合は、ホワイトリストを適用します—サーバー側の積極的な入力検証。
XLMプロセッサとライブラリを定期的にアップグレードしてください。
機密データのシリアル化を防止します。
該当する場合は、JSONまたは同様の単純な形式を使用してください。
Webアプリケーションファイアウォール（WAF）とAPIセキュリティゲートウェイを実装します。

既知の脆弱性を持つコンポーネントの使用

完璧なものはありません。ソフトウェアで使用するコンポーネントには、既知または未知の脆弱性があります。発見および認識された脆弱性に対応して、ソフトウェアが更新され、それらの脆弱性をカバーするか、それらの悪用によって引き起こされる可能性のある損害を軽減します。いくつかの弱点は小さな損害を引き起こしますが、他の弱点はあなたのビジネスを傷つけているかもしれません。

既知の脆弱性によるWebサイトのハッキングを防ぐには、定期的に更新を確認し、Webサイトで使用されているすべてのコンポーネントを更新することが重要です。これは、コンポーネントが多いソフトウェアやWebサイトでは面倒な作業になる可能性があります。そのため、セキュリティの専門家は、不要な未使用のライブラリ、機能、ファイル、およびその他のコンポーネントを定期的にチェックして削除することを推奨しています。そしてもちろん、公式ソースのコンポーネントのみを使用してください。通常は有料のソフトウェアを無料で配布しているWebサイトに惑わされないでください。Webサイトをハッキングするように変更することができます。

安全なウェブサイトを作成する方法：収益

安全なウェブサイトを作成する方法

技術に重点を置いたすべての情報を素人の言葉で表現するために、安全なWebサイトを作成する場合に従うべきセキュリティのヒントを次に示します。

信頼できるウェブホストを見つけましょう。
Webサイトで使用されているすべてのソフトウェア、フレームワーク、およびライブラリを定期的に更新します。
Webサイトから不要な機能やコンポーネントを削除します。
ブラウザ側とサーバー側の両方で入力を検証するようにシステムを設定します。
エラーメッセージに表示される情報を監視します。
ユーザーのパスワード強度チェッカーを設定します。
サーバーと管理ページには常に強力なパスワードを使用し、定期的に変更してください。
SSL証明書に投資する/ HTTPSプロトコルを使用する。
障害とエラーの適切なログを設定します。
監査トランザクションをログに記録します（特に、eコマースWebサイトの場合）。
ログを注意深く監視します。
クラウドサーバーを使用しますが、それでもデータを保護します。
常に最新のテクノロジーを使用して機密データを暗号化します。
セキュリティチームに、攻撃にタイムリーに対応できるように、新しいセキュリティアップデートと新しい脅威を監視してもらいます。

ウェブサイトを保護するのにどれくらいの費用がかかりますか？

これは明確な答えがない質問です。セキュリティのコストは、サイトで使用する技術スタックに大きく依存します。 さらに、更新のコストがあります。これは、更新する必要のあるコンポーネントの数、コンポーネントを更新する頻度、および各コンポーネントの更新にかかるコストによって異なります。これらのコストは、開発者が個別に計算する必要があります。

開発当初からセキュリティを考慮することを強くお勧めします。 セキュリティの問題を最後まで残すと、サイトのコアに変更を加える必要が生じる可能性があります。これは、最初からセキュリティを組み込むよりもさらにコストがかかる可能性があります。

結論

あなた自身が開発者である場合、開発会社を所有している場合、または社内の開発チームを持っている場合は、これらすべてのタスクをそれらの前に設定できます。ただし、技術スペシャリストがまだいない場合で、アウトソーシングプロバイダーとの安全なウェブサイトを作成する方法を知りたい場合は、ウェブサイトを構築するだけでなく、それをサポートできる開発会社を見つけることをお勧めします。すべての脆弱性を予測することはほぼ不可能ですが、違反にタイムリーに対応する機能により、最悪の運命からWebサイトを救うことができます。

Mind Studiosの開発者は、セキュリティのベストプラクティスに精通しており、最新のトレンドに対応しています。あなたのウェブサイトをハッカーから保護する方法について質問がある場合は、無料相談のために私達に連絡してください。

SvitlanaVaraksinaとArtemChervichnikによって書かれました