<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های Saeiez</title>
        <link>https://virgool.io/feed/@bussinesman2030</link>
        <description></description>
        <language>fa</language>
        <pubDate>2026-06-16 12:35:46</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/3080666/avatar/4wNKMU.png?height=120&amp;width=120</url>
            <title>Saeiez</title>
            <link>https://virgool.io/@bussinesman2030</link>
        </image>

                    <item>
                <title>Vulnerability XXE</title>
                <link>https://virgool.io/@bussinesman2030/vulnerability-xxe-wxrlppzcojdu</link>
                <description> آسیب‌پذیری XXE چیست؟تزریق  XXE ( XML External Entity) نوعی از آسیب‌پذیری در امنیت وب است که یک  مهاجم به واسطه‌ی آن می‌تواند در فرایند پردازش داده‌های XML توسط یک  وب‌اپلیکیشن مداخله کند. این آسیب‌پذیری معمولا مهاجم را قادر می‌کند که  فایل‌هایی را که روی فایل‌سیستم سرور اپلیکیشن قرار دارند مشاهده کند، و با  هر سیستم بک‌اند یا خارجی که خود اپلیکیشن قادر به دسترسی آن باشد، تعامل  کند.آسیب‌پذیری XXE چگونه به وجود می‌آید؟بعضی از اپلیکیشن‌ها، داده‌های بین مرورگر و سرور را در قالب فایل‌های XML  انتقال می‌دهند. این نوع اپلیکیشن‌ها تقریبا همیشه از یک کتابخانه‌ی  استاندارد یا API متناسب با پلتفرم خود برای پردازش داده‌های XML روی سرور  استفاده می‌کنند. آسیب‌‌پذیری‌های XXE به این خاطر به وجود می‌آیند که XML  در تعریف  خود ذاتاً امکاناتی دارد که بالقوه خطرناک هستند، و حتی اگر برخی  از این امکانات مورد نیاز یک اپلیکیشن نباشد، باز هم پارسرهای* استاندارد XML از تمام این امکانات پشتیبانی می‌کنند.همان‌طور که پیش از  این گفتیم، انتیتی‌های اکسترنال در XML، نوعی از Custom Entity هستند که  مقدار تعریف‌شده برای آن‌ها، از جایی خارج از DTD که در آن تعریف شده‌اند  بارگیری می‌شود. این انتیتی‌های خارجی از منظر امنیت اهمیت ویژه‌ای دارند،  زیرا این امکان را به وجود می‌آورند که یک انتیتی براساس محتویات یک آدرس  فایل یا URL تعریف شود.* XML Parser یا XML پروسسور برنامه یا ماژولی است که وظیفه‌ی تجزیه‌ی فایل‌های XML را دارد تا داده‌های آن‌ها قابل خواندن و استفاده باشد.نواع حملات XXE کدامند؟حملات XXE انواع مختلفی دارند. چند نوع از حملات XXE Injection عبارتند از:اکسپلویت  XXE برای دستیابی به فایل‌ها: در این نوع حمله یک External Entity با  محتویات یک فایل خاص تعریف می‌شود، و این محتویات در پاسخ وب‌اپلیکیشن  بازگردانده می‌شوند.اکسپلویت XXE برای انجام حمله SSRF: در این نوع حمله یک External Entity با لینک حاوی آدرس یک سیستم بک‌اند تعریف می‌شود.اکسپلویت  blind XXE برای استخراج داده به صورت out-of-band: در این نوع حمله،  داده‌های حساس از سرور اپلیکیشن به سیستمی انتقال داده می‌شوند که در کنترل  مهاجم است.اکسپلویت blind XXE برای دستیابی به  داده‌ها و پیام‌های خطا: در این نوع حمله، مهاجم می‌تواند باعث ایجاد یک  parsing error* شود که حاوی اطلاعات حساس است.اکسپلویت XXE برای دستیابی به فایل‌هابرای مثال، یک اپلیکیشن خرید را در نظر بگیرید که با ارسال فایل XML زیر به سرور، موجودی یک محصول خاص در انبار را بررسی می‌کند:&lt;?xml version=&amp;quot1.0&amp;quot encoding=&amp;quotUTF-8&amp;quot?&gt;                             &lt;!DOCTYPE Saeed [&lt;!ENTITY file SYSTEM &amp;quotfile:///etc/passwd&amp;quot&gt;]&gt;&lt;stockCheck&gt;
&lt;productId&gt; 
&amp;file;
&lt;/productId&gt;
&lt;storeId&gt;3
&lt;/storeId&gt;
&lt;/stockCheck&gt;
این پی‌لود XXE یک انتیتی اکسترنال به نام fileایجاد می‌کند که مقدار آن،  محتویات فایل /etc/passwd است، و سپس از این انتیتی، در مقدار productID  استفاده می‌کند. این کار باعث می‌شود پاسخ اپلیکیشن، شامل محتویات فایل  باشد:نکته: در آسیب‌پذیری‌های واقعی XXE، معمولا در یک فایل  XML ثبت‌شده، تعداد زیادی مقادیر داده وجود دارند، که هر کدام از آن‌ها  ممکن است در پاسخ اپلیکیشن به کار روند. برای این که بتوانید به صورت  سیستماتیک و با یک رویه‌ی قابل اعتماد وجود آسیب‌پذیری‌های XXE را بررسی  کنید، معمولا نیاز است تک‌تک Data Nodeها، یعنی همه‌ی جاهایی را که در فایل  XML داده‌‌ای آمده است، به طور جداگانه بررسی کنید. برای بررسی هم باید یک  انتیتی تعریف کنید و آن را جای داده‌ی مورد نظر قرار دهید و ببینید مقدار  آن در پاسخ اپلیکیشن بازگردانده می‌شود یا خیر.</description>
                <category>Saeiez</category>
                <author>Saeiez</author>
                <pubDate>Sun, 10 Mar 2024 17:59:00 +0330</pubDate>
            </item>
                    <item>
                <title>CSRF</title>
                <link>https://virgool.io/@bussinesman2030/csrf-igsf6vbzef8w</link>
                <description>جعل درخواست یا CSRF (Cross Site Request Forgery) یک آسیب‌پذیری وب است که Attacker با استفاده از آن می‌تواند کاری کند که قربانی اقداماتی را انجام دهد که قصد انجام آن‌ها را نداشته‌.به عنوان مثال تصویر زیر که نشان میدهد  قربانی با کلیک بروی پیوندی باعث اجرا کردن یک اسکریپت مخرب شده است که آدرس ایمیل او بصورت ناخواسه عوض شده استمعمولاً در این نوع حمله، هکرها از کوکی‌های مرورگر یا پارامترهای URL برای انجام درخواست‌های تقلبی استفاده می‌کنند. این درخواست‌ها ممکن است عملیات حذف، ویرایش یا افزودن داده‌ها را در سایت هدف انجام دهند و می‌تواند منجر به خسارت جدی و نقض امنیت سایت شودچگونه کار می‌کند؟  برای اجرای حمله CSRF سه شرط کلیدی زیر باید وجود داشته باشد:اجرای اقدام مرتبط توسط مهاجم: یک اقدام مرتبط در داخل برنامه‌کاربردی که مهاجم دلیلی برای انجام آن داشته باشد. این اقدام ممکن است شامل تغییر مجوز و سطح دسترسی سایر کاربران یا هر اقدامی در خصوص داده‌های خاص کاربر (مانند تغییر رمز عبور خود کاربر) باشد.امکان دست‌درازی به جلسه جاری (Session) بر مبنای کوکی: انجام این عمل شامل ارسال یک یا چند درخواست HTTP (HTTP Request) است. دراین حالت، برای اینکه حمله CSRF اجرا شود، نرم‌افزار کاربردی برای شناسایی کاربری که درخواست‌ها را ارسال کرده، تنها به کوکی‌های Session متکی است. هیچ مکانیسم دیگری برای ردیابی و پویش Session یا اعتبارسنجی درخواست‌های کاربر وجود ندارد.قابل پیش‌بینی بودن تمام پارامترهای درخواست موردنظر: درخواست‌هایی که منجر به حملات CSRF می‌شوند نباید حاوی پارامتری باشند که مهاجم نتواند مقادیر آنها را تعیین کند یا حدس بزند. به عنوان مثال، هنگامی که مهاجم کاربر را وادار به تغییر رمز عبور خود می‌کند، اگر مهاجم نیاز به دانستن مقدار رمز عبور فعلی باشد، کاربر نسبت به تغییر رمزعبور آسیب‌پذیر نخواهد بود.به عنوان مثال، فرض کنید یک وب سایت کاربردی دارای قابلیتی است که به کاربر اجازه تغییر نشانی ایمیل حساب را می‌دهد. هنگامی که کاربر این اقدام را انجام می‌دهد، یک درخواست HTTP مانند زیر ارسال می‌شود:این درخواست HTTP شرایط لازم برای اجرای یک حمله CSRF را دارا می‌باشد:عمل تغییر نشانی ایمیل مربوط به یکی از حساب‌های کاربری. پس از این تغییر نشانی، مهاجم معمولاً قادر به تنظیم مجدد رمز عبور و کنترل کامل حساب کاربری خواهد بود.این برنامه‌کاربردی از کوکی جلسه (Session Cookie) برای تشخیص اینکه کدام کاربر درخواست را ارسال کرده، استفاده می‌کند. هیچ نشانه یا مکانیزم دیگری برای ردیابی جلسات‌جاری (Session) کاربر وجود ندارد.مهاجم به راحتی می‌تواند مقادیر پارامترهای درخواستی برای انجام اقدام مورد نیاز را تعیین کند.با برآورده شدن این سه شرط بالا، مهاجم می‌تواند صفحه وبی حاوی کد HTML زیر ایجاد نماید:&lt;iframe style=&amp;quotdisplay:none&amp;quot name=&amp;quotcsrf-frame&amp;quot&gt;&lt;/iframe&gt;
&lt;form method=&#039;POST&#039; action=&#039;https://0a7c0031031426d88cd511b00089008a.web-security-academy.net/my-account/change-email&#039; target=&amp;quotcsrf-frame&amp;quot id=&amp;quotcsrf-form&amp;quot&gt;
 &lt;input type=&#039;email&#039; name=&#039;email&#039; value=&#039;Test2@gmail.com&#039;&gt;
&lt;/form&gt;
document.getElementById(&amp;quotcsrf-form&amp;quot).submit()اگر کاربر قربانی از صفحه وب مهاجم بازدید کند، موارد زیر رخ می‌دهد:صفحه مهاجم یک درخواست HTTP را به وب سایت آسیب‌پذیر ارسال می‌کند.اگر کاربر به وب سایت آسیب‌پذیر وارد شده باشد (لاگین کرده باشد)، مرورگر او به طور خودکار کوکی جلسه (Session Cookie) خود را در درخواست می‌آورد (با فرض اینکه از قابلیت SameSite در کوکی‌ها استفاده نشده باشد).وب‌سایت آسیب‌پذیر درخواست را به روش معمولی پردازش می‌کند؛ آن را همانند سایر درخواست‌های کاربر قربانی، قلمداد نموده و نشانی ایمیل این کاربر را تغییر می‌دهد.</description>
                <category>Saeiez</category>
                <author>Saeiez</author>
                <pubDate>Wed, 31 Jan 2024 17:31:29 +0330</pubDate>
            </item>
                    <item>
                <title>آسیب پذیری  CORS</title>
                <link>https://virgool.io/@bussinesman2030/%D8%A2%D8%B3%DB%8C%D8%A8-%D9%BE%D8%B0%DB%8C%D8%B1%DB%8C-cors-wpgqnkyy14ba</link>
                <description>آسیب پذیری CORS Misconfigurationآسیب پذیری CORSکه مخفف عبارت Cross-origin resource sharingیک آسیب پذیری خطرناک محسوب میشود. به این دلیل که نفوذگر میتواند اطلاعات حساس مانند SESSION یا APIKEY... را بدست بیاورد اما این آسیب پذیری ارتباط مستقیمی با SOPدارد  اما دلیل استفاده از CORS  چیست  ؟Cross Origin Resource Sharing (CORS) برای غلبه بر محدودیتهای Same Origin Policy (SOP) در امکان تبادل اطلاعات از منابع (Origin) مختلف، معرفی شد. به تعامل بین مبدا (Origin)های مختلف Cross Domain و بین مبدا (Origin)های یکسان Same Origin گفته می شود.در واقع CORS  یک ویژگی که این امکان را فراهم می کند تا بین منابع متفاوت تبادل اطلاعات انجام شودبرای درک بهتر این آسیب پذیری ابتدا SOP  را تعریف و محدودیت های آن را تشریح میکنیمزSOP  یک ویژگی امنیتی در مرورگر هاست که اجازه میدهد ORIGIN یکسان باهم ارتباط داشته باشندبه تصویر زیر دقت کنید SOP جلوگیری کرد از اینکه به مبدا (Origin) متفاوت درخواستی زده شود به همراه کوکی و نشست احراز هویت شدهبا سه روش میتوان این محدودیت هارو دور زد که عبارتند از :1-POST MESSAGE2-JSONP3-CORSه    CORS   چیست؟ ئ CORS   جهت مدیریت ارتباط بین  originهای متفاوت ایجاد شده است. اغلب وب­سایت­ها، ساب­دامین­ها وThird Party  سایت­ها از طریق همین ویژگی با یکدیگر تبادل اطلاعات انجام می دهند.آسیب پذیری CORS  چه زمانی رخ می­دهد؟اگر تنظیمات CORS به درستی انجام نشده باشد، ممکن است که سرور در موارد غیر مجاز، پاسخ درخواست یک origin غیر معتبر را داده و اطلاعات مهم کاربر نشت پیدا کند.به تصویر زیر توجه کنید. دو درخواست یکسان از یک مبدأ به وبسایت  mainsite.com ارسال شده است.نحوه تشخیص آسیب پذیری CORS Misconfigurationبرای تشخیص این آسیب پذیری، می توان Headerها را بررسی نمود. برخی از هدرهای مهم در این رابطه عبارتند از:و  Access-Control-Allow-Origin -&gt; تعیین می­کند آیا origin مدنظر اجازه دارد به وب­سایت مقصد درخواستی را ارسال کند یا خیر؟و Access-Control-Allow-Credentials -&gt; تعیین می­کند آیا همراه درخواستی که ارسال می­شود، کوکی­هم ارسال می­شود یا خیر؟ باید دقت داشت که مقدار این هدر حتما باید true  باشد.یکی از روش­های مرسوم جهت کشف آسیب پذیری CORS Misconfiguration، تعویض Origin  وب سایت باOrigin  مهاجم است. اگر در داخل پاسخ سرور  هدرهای Access-Control-Allow-Origin   و Access-Control-Allow-Credentials وجود داشته باشد و یا Origin مهاجم رفلکت شود، آسیب پذیری CORS Misconfiguration  واقع شده است.نکته باید توجه داشت که صرف وجود CORS Misconfiguration ممکن است آسیب پذیری مهمی قلمداد نشود؛ زیرا اطلاعات مهمی از کاربران برای نشت وجود نداشته باشدباید ب دنبال یک ENDPOINT  گشت که اطلاعات مهم را نمایش دادبرای  درک بهتر آسیب پذیری CORS Misconfiguration  از آزمایشگاه آکادمی Portswigger  کمک گرفته شده است.در تصویر بالا یک EndPoint  داریم که اطلاعات حساسی را به ما نمایش میدهددر خط دوم Access-Control-Allow-Credentialsمقدارش TRUE  میباشد به این معنیه که کوکی با درخواست ارسال میشودخب حالا یک Origin  دلخواه ست میکنیم و درخواست را ارسال میکنیمشرط دوم هم وجود دارد Access-Control-Allow-Originبا مقداری که ارسال کردیم ست شده استحالا به سراغ اکسپلویت کردن آسیب پذیری میرویم با قطعه کد زیر اکسپلویت را انجام میدهیمحالا با دادن لینکی که کد مخرب ما در اونجا قرار دارد اطلاعات قربانی برای ما ارسال میشودهمانطور که در تصویر مشاهده میکنید اطلاعات قربانی براما ارسال شده استشماتیک الگوریتم انجام این حمله را می توان در تصویر زیر خلاصه کرداز اینکه برای این مقاله  وقت گذاشتید  متشکرمپایان</description>
                <category>Saeiez</category>
                <author>Saeiez</author>
                <pubDate>Thu, 25 Jan 2024 19:43:08 +0330</pubDate>
            </item>
            </channel>
</rss>