حمله Cross-Site Scripting یا XSS چیست؟ چگونه از این حمله جلوگیری نماییم؟

Cross-Site Scripting یا همان XSS یکی از روش های هک کردن وبسایت می باشد. این مقاله در رابطه با حمله XSS و نحوه جلوگیری از آن در صفحات ASP.NET می باشد.

حمله Cross-Site Scripting یا XSS چیست؟ چگونه از این حمله جلوگیری نماییم؟

حمله Cross-Site Scripting یا XSS چیست؟

Cross-Site Scripting که معمولا با نام XSS نامیده می شود آسیب پذیری می باشد که در همه وبسایت ها موجود است. با استفاده از این آسیب پذیری مهاجم می تواند از مزیت های زیادی بهره برده و با درج تعدادی script مخرب که این script ها با اجرا شدن به صورت خودکار قابلیت آن را دارند که هر کاری که مهاجم می خواهد را انجام نمایند. برای مثال مهاجم می تواند تعدادی کد جاوا اسکریپت با ورودی واقعی در فیلد ورودی درج کند که به نوبت در زمان نمایش در مرورگر اجرا شوند.

حمله XSS به طور گسترده به 2 نوع دسته بندی می شوند : Stored(ذخیره شده) و Reflected(منعکس). حمله Stored XSS شده حمله ای است که ورودی با کد مخرب دائما درون رسانه ای مانند بانک اطلاعاتی ذخیره شده و هر زمانی که نمایش پیدا کرد اجرا گردد. برای مثال مخرب می تواند در فیلد توضیحات تعدادی اسکریپت مخرب درج نماید که به هنگام نمایش در مرورگر اجرا گردند.
 حمله Reflected XSS شده حمله ای است که اسکریپت مخرب با ورودی، تنها توسط سرور پردازش شده و منعکس گردد. برای مثال ورودی در مرورگر دوباره برای کاربر نمایش داده شود که عموما در صفحه های جستجو دیده می شود : “You have searched for …” یا در بعضی جاها زمانی که با پیغام خطایی مبنی بر وارد کردن ورودی اشتباه از کاربر مواجه می شوید مانند : “.Your input ... is invalid” . در این موارد اگر اسکریپت مخرب با ورودی تزریق شده باشد توسط مرورگر اجرا می گردد. در این جا با تعدادی XSS attack ساده در ASP.NET آشنا می شویم.

شبیه سازی حمله XSS در ASP.NET

به طور پیش فرض ASP.NET اجازه هیچ نوع تگ html را نمی دهد. در این مورد شما با وارد کردن تگ های html و ارسال صفحه با پیغام خطای زیر مواجه خواهید شد :

A potentially dangerous Request.Form value was detected from the client

توجه داشته باشید که شما برای قبول کردن ورودی html باید در این صفحات ValidateRequest را False قرار دهید. یک پروژه ASP.NET جدید در visual studio ساخته سپس یک کنترل textbox با نام txtMessage و یک button با نام btnSubmit به صفحه aspx اضافه کرده و همچنین در web.config در قسمت <system.web> کد زیر را کپی نمایید.

<pages validateRequest="false" />

webform1.aspx.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace WebApplication5
{
    public partial class WebForm1 : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {

        }

        protected void btnSubmit_Click(object sender, EventArgs e)
        {

            Response.Write(txtMessage.Text);

        }
    }
}

webform1.aspx

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="WebForm1.aspx.cs" Inherits="WebApplication5.WebForm1" %>

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
    <style type="text/css">
        .auto-style1 {
            text-align: center;
        }
    </style>
</head>
<body>
    <form id="form1" runat="server">
    <div class="auto-style1">
    
        <asp:TextBox ID="txtMessage" runat="server" Width="775px"></asp:TextBox>
        <br />
        <br />
        <asp:Button ID="btnSubmit" runat="server" OnClick="btnSubmit_Click" Text="ارسال" />
    
    </div>
    </form>
</body>
</html>

حالا برنامه را اجرا کرده و در textbox اسکریپت زیر را کپی نمایید :

<script>alert('شما هک شدید!!')</script>

زمانیکه روی دکمه کلیک کنید اسکریپت مخرب اجرا شده و شما با پیغام خطای زیر روبرو می شوید :

این یک مثال بسیار ساده بود که تنها یک alert box نمایش داده شده و هیچ اثرات خطرناک دیگری دیده نشد. فرض کنید یک فیلد توضیحات در صفحه شما موجود است که این فیلد با توجه به نیاز شما قابلیت گرفتن ورودی html هم دارد. حالا مهاجم یا احتمالا دزد می تواند اسکریپتی در آن وارد کند که تمام کاربران سایت شما (ترافیک سایت)  که مشغول بازدید سایت شما بودند را به سایت خود ببرد.

مثلا در text box مثال قبل اسکریپت زیر را وارد کنید :
 

<meta http-equiv="refresh" content="2;url=http://www.barnamenevisan.org/">

این اسکریپت پس از اجرا شما را به سایت www.barnamenevisan.org می برد.

مدیریت حمله XSS در ASP.NET

برای مدیریت حمله XSS در این صفحات شما می توانید ورودی های html را قبل از پردازش آنها رمزنگاری نمایید. ورودی html رمزنگاری شده از درجه اعتبار ساقط خواهد شد و بدون اجرا شدن به سادگی به نمایش در خواهد آمد. از این رو شما در مثال قبلی می توانید با تکه کد زیر از وقوع حمله XSS جلوگیری نمایید :
 

protected void btnSubmit_Click(object sender, EventArgs e)

    {

        Response.Write(Server.HtmlEncode(txtMessage.Text));

    }

کد بالا ورودی html وارد شده را رمزنگاری نموده بنابراین کد بالا پس از رمزنگاری چنین می شود :
 

&lt;script&gt;alert('شما هک شدید!')&lt;/script&gt;

&lt;meta http-equiv=&quot;refresh&quot; content=&quot;2;url=http://www.codedigest.com/&quot;&gt;

حالا زمانی که این کد در مرورگر اجرا می شود تگ های html مانند فایل های متنی(text) غیر قابل اجرا می شوند. به کد زیر دقت نمایید :

<script>alert('You are hacked!')</script>

<meta http-equiv="refresh" content="2;url=http://www.barnamenevisan.org/">

در مواقعی شما نیاز به این دارید که کاربر تگ html وارد نماید. برای مثال در صفحه وارد کردن مقاله در سایت ما یک text editor (ویرایشگر متن) برای ورود متن مقاله و ذخیره آن بدون رمزنگاری وجود دارد. در این موارد برای جلوگیری از حمله XSS شما باید کاربر را برای اجازه استفاده از تگ های html محدود نمایید مثلا اجازه استفاده از تگ های <font><I><B> و غیره را بدهید. همچنین می توانید استفاده از تگ های آسیب پذیر حمله XSS را سمت سرور اجازه ندهید.

تعدادی از حملات XSS مرسوم در دنیای وب

1- مهاجم تعدادی لینک html می فرستد که کاربران با کلیک روی آنها به سایت مهاجم فرستاده می شوند. اغلب این شیوه در قسمت توضیحات و تالار گفتگو (forum) استفاده می شود.

2- مهاجم تعدادی اسکریپت می فرستد که می تواند به صورت خودکار کاربران را به سایت خودش رجوع دهد.

3- مهاجم تعدادی اسکریپت مخرب می فرستد که می تواند اطلاعات login و کوکی و Session کاربر را بدزدد. با sessionid مهاجم می تواند هنگام login کردن کاربر با همان sessionid به هر چه که می خواهند دست یابند.

نکته: در جاوااسکریپت شما می توانید با استفاده از خاصیت document.cookie کوکی را بگیرید. شما با استفاده از ابزاری مانند burp proxy که برای شبیه سازی این سناریو ها می باشد، می توانید با دستکاری در http request وارد session دیگر کاربران شوید.

نتیجه

امروزه اکثر فریم ورک های پیشرفته همه مکانیزم های لازم برای جلوگیری از حمله XSS را دارا می باشند. اما هنوز در مواقعی که نیاز به ورود html از کاربر باشد، باید به موارد زیر دقت کرد :

1- به غیر از زمانی که نیاز است در web.config گزینه ValidateRequest برابر با false نباشد.

2- هنگامی که ValidateRequest برابر با false است از رمزنگاری ورودی html استفاده شود. تنها در زمانی که لازم است از رمزنگاری خودداری شود.

3- هنگام فراهم کردن ویرایشگر متن برای کاربر از تگ هایی مانند <iframe><script><applet><img>

سمت سرور استفاده نشود.

فایل های ضمیمه