CMS 1C-Bitrixで作成されたサイトの体系的な脆弱性

商用CMSで作成されたサイトの体系的な脆弱性について書くために、「保護された」CMSをハッキングするリスクを説明する投稿をプッシュしました。



この記事は、「ヒューマンファクター」によるリソースの侵害に焦点を当てており、「脆弱性のない」CMSの存在を前提として、サイトの脆弱性とWeb攻撃を悪用するトピックを回避しました。 たとえば、CMS 1C-Bitrixの既製のオンラインストアの「箱から出してすぐに」のセキュリティは非常に高く、「ボックスバージョン」コードで多かれ少なかれ深刻な脆弱性を見つける可能性は低いと考えられます。 。



もう1つは、このようなCMSで作成された最終製品のセキュリティであり、最も重要なのは、これらのサイトでの高レベルの脆弱性の発現の体系です。 サイトのセキュリティ(InSafety)およびプラットフォームの脆弱性(CMS)で収集する統計の確保に基づいて、個人ユーザーアカウントを使用して1C-Bitrixプラットフォームで作成されたサイトの50%以上が保存されて動作する可能性がありますXSS攻撃。



プラットフォーム: CMS 1C-Bitrix 15.0以降

セキュリティの脅威: XSS Stored Attack

システマティクス:ユーザーアカウントを持つサイトの少なくとも50%


XSS攻撃の操作を可能にするコードの脆弱性は、データベースに送信されるリソースの個人ユーザーアカウントの登録情報フォームのフィールドのデータのフィルタリングが不十分であることにあります。







開発者は、Bitrix APIを使用して、たとえば$ _REQUESTのユーザー名などのデータを保存します。その後、完全にフィルター処理されず、タグが保存されます。 たとえば、ユーザーサイトLCのフォームフィールド「名前」に行を渡します。



test"><a href='#'><img src='http://insafety.org/img/xss2.jpg'/></a><p
      
      





画像






データは通常の入力を介して$ _POST ['name']に転送され、次に$ USER-> Updateに転送されます。たとえば、次のようになります。



 $USER->Update($USER->GetID(),array( 'NAME' => $_POST['name'], ));
      
      





HTMLコードはサニタイズされず、ユーザー名に「現状のまま」保存されます。 サイト管理パネルのスクリーンショット:



画像






結果:



画像








この例は、セキュリティリスクを明確に示しています。



脅威の存在の提案されたデモンストレーションでは、典型的なXSS攻撃を示唆するJSではなくHTMLコードの実装が示されました。 これは、CMS 1C-Bitrixで開発されたほとんどのサイトでは、JSコードを実装しようとするとプロアクティブな防御フィルターがブロックされるためです。



HTMLコードのほとんどの構文タグの実装、CMS 1C-Bitrixの予防的な防御はフィルタリングされません。 このコードの脆弱性検出のデモンストレーションは、完全に安全かつ明確です。 何らかの理由で1C-Bitrixプロアクティブ防御フィルターが無効になっている場合、上記のコードの脆弱性により、「クラシック」実装での保存されたXSS攻撃の悪用が可能になります。



(JSかHTMLかにかかわらず)不正なコードの導入によるサイトのセキュリティリスクのレベル、および適切なフィルタリングなしの出力は非常に高くなります。



明らかな理由から、この記事では、プロアクティブな防御フィルターの有無にかかわらず、攻撃の実際の操作に対するオプションを提供していません。



XSS攻撃からの保護



XSS攻撃を悪用する可能性からサイトを保護することは非常に簡単です。 これを行うには、文字をエスケープし、特殊文字をHTMLエンティティに変換することにより、入力データと出力データをフィルタリングします。 PHPでは、これはhtmlspecialchars()、htmlentities()、strip_tags()関数を使用して実行できます。



例:



 $name = strip_tags($_POST['name']); $name = htmlentities($_POST['name'], ENT_QUOTES, "UTF-8"); $name = htmlspecialchars($_POST['name'], ENT_QUOTES);
      
      





さらに、サイトページのエンコードを明示的に指定する必要があります。



 Header("Content-Type: text/html; charset=utf-8");
      
      





XSS攻撃から保護するには多くの方法があります。たとえば、Webサーバー構成レベルで引用符と括弧の転送を禁止するオプション(ブラックリストによるデータのフィルタリング)があります。



NGINXの例:(構成ファイルへの書き込み)



 location / { if ($args ~* '^.*(<|>|").*'){ return 403; } if ($args ~* '^.*(%3C|%3E|%22).*'){ return 403; } }
      
      





Apache Webサーバーの場合、これは.htaccessファイルのエントリになります。



 RewriteEngine on RewriteCond %{HTTP_USER_AGENT} (<|>|"|%3C|%3E|%22) [NC,OR] RewriteRule ^{}
      
      





ブラックリストデータフィルタリングは、すべてのサイトに適用できるわけではありません。 攻撃に対するこの保護方法を使用するには、法的要求をブロックできるため、非常に注意する必要があります。



おわりに



前述のWebアプリケーションのセキュリティリスクは、最も一般的で有名な攻撃です。 XSS攻撃とそれらに対する保護について、何千もの記事や出版物が書かれています。



当社の実務において、2015年秋にユーザーアカウントのXSS攻撃に対する脆弱性が発見されました。 2016年の春、CMS 1C-Bitrixの脆弱なサイトの統計では、調査中のサイトの50%以上が悪用される可能性があることが明確に示されました。 2016年4月、このセクションのコードの脆弱性が本質的に全身性であることを認識し、セキュリティリスクに関するすべての情報をBitrixに送信しました。 Bitrixの従業員は情報を受け入れ、システムのドキュメントを修正することで行動を起こしたとフィードバックで言いました。 対策が講じられているにもかかわらず、1C-Bitrix上のサイトに対する上記のセキュリティリスクは、今日でも非常に重要です。



この情報が1C-Bitrixプラットフォームで作成されたサイトの開発者と所有者に役立つことを願っています。



あなたは、犯罪目的のために攻撃を悪用することは言うまでもなく、他の人のサイトのセキュリティを実験することは刑事責任につながる可能性があることを理解する必要があります。 この投稿では、サイトのセキュリティに対する脅威に関するすべての情報は、1C-Bitrixプラットフォーム上の最終製品の情報セキュリティの全体的なレベルを高めることを目的として提供されています。



All Articles