“[Session-hijacking-prevention] [Author] Session hijacking and prevention methods added”

Session-hijacking-prevention/README.md

@@ -0,0 +1,78 @@
+
+# مقدمه 
+![image](https://github.com/user-attachments/assets/a170243c-a035-4480-b612-0ad62ed68e3e)
+تصویر برگرفته شده از invicti.com - What Is Session Hijacking: Your Quick Guide to Session Hijacking Attacks
+# نشست ربایی یا Session hijacking
+نشست ربایی(session hijacking که گاها به آن cookie hijacking هم گفته می‌شود) به بهره‌برداری از ID جلسه معتبر کامپیوتری — که گاهی اوقات به آن کلید جلسه نیز گفته می‌شود — برای دستیابی غیرمجاز به اطلاعات یا خدمات در یک سیستم کامپیوتری اشاره دارد. این حمله به دانش مهاجم از کوکی جلسه شما وابسته است، بنابراین به آن سرقت کوکی یا cookie side-jacking نیز گفته می‌شود. اگرچه هر جلسه کامپیوتری می‌تواند مورد حمله قرار گیرد، سرقت نشست بیشتر در مورد نشست‌های مرورگر و برنامه‌های وب صدق می‌کند.
+
+# دلایل اهمیت session hijacking
+اگر حمله موفقیت‌آمیز باشد، مهاجم می‌تواند هر عملیاتی را که کاربر اصلی در حین جلسه فعال مجاز به انجام آن است، انجام دهد. بسته به موقعیت، این ممکن است به معنای انتقال پول از حساب بانکی کاربر، تقلید از کاربر برای خرید کالا از فروشگاه‌های آنلاین، دسترسی به اطلاعات شخصی دقیق برای سرقت هویت، سرقت داده‌های شخصی مشتریان از سیستم‌های شرکتی، رمزگذاری داده‌های ارزشمند و درخواست پول برای رمزگشایی آنها و انواع دیگر عواقب ناخوشایند باشد.
+
+یک خطر خاص برای سازمان‌های بزرگ این است که کوکی‌ها می‌توانند برای شناسایی کاربران احراز هویت‌شده در سیستم‌های ورود یکپارچه (SSO) استفاده شوند. این بدان معناست که یک حمله موفق به سرقت جلسه می‌تواند به مهاجم دسترسی به SSO برای چندین برنامه وب بدهد، از سیستم‌های مالی و سوابق مشتریان گرفته تا سیستم‌های کسب‌وکار که ممکن است شامل دارایی‌های معنوی ارزشمند باشند. برای کاربران فردی، خطرات مشابهی نیز زمانی که از خدمات خارجی برای ورود به برنامه‌ها استفاده می‌شود وجود دارد، اما به دلیل تدابیر امنیتی اضافی هنگام ورود با استفاده از حساب‌های فیس‌بوک یا گوگل، معمولاً سرقت کوکی جلسه برای سرقت جلسه کافی نخواهد بود.
+
+## حملات متداول:
+- **حمله اسکریپت‌نویسی متقابل(Cross-site scripting) یا XSS**: این احتمالاً خطرناک‌ترین و گسترده‌ترین روش سرقت جلسه وب است. با بهره‌برداری از آسیب‌پذیری‌های سرور یا برنامه، مهاجمان می‌توانند اسکریپت‌های سمت کلاینت (معمولاً جاوااسکریپت) را به صفحات وب تزریق کنند و باعث شوند که مرورگر شما هنگام بارگذاری صفحه آسیب‌دیده، کد دلخواهی را اجرا کند. اگر سرور ویژگی HttpOnly را در کوکی‌های جلسه تنظیم نکرده باشد، اسکریپت‌های تزریق‌شده می‌توانند به کلید جلسه شما دسترسی پیدا کنند و اطلاعات لازم برای سرقت جلسه را در اختیار مهاجمان قرار دهند.
+![image](https://github.com/user-attachments/assets/5d11c5fe-02ff-439a-bb32-c8ac51be132e)
+
+- **تثبیت نشست(session fixation)**: در این روش نفوذگر کلید جلسه شخص مورد هدف را آن چیزی قرار می‌دهد که خود می‌خواهد. از این طریق شخص قربانی با وارد شدن به سایت (همراه با کلید جلسه که نفوذگر به او تحمیل کرده) این امکان را به مهاجم می‌دهد تا با استفاده از همان کلید جلسه خود را به جای قربانی معرفی کند.روش‌های زیادی برای انجام این کار وجود دارد، به‌عنوان مثال با استفاده از پارامترهای کوئری HTTP در یک لینک طراحی‌شده که از طریق ایمیل ارسال شده یا در یک وب‌سایت مخرب ارائه می‌شود. برای مثال:
+```yml
+<a href="http://www.TrustedSite.com/login.php?sessionid=iknowyourkey">Click here to log in now</a>
+```
+زمانی که قربانی روی لینک کلیک می‌کند، به یک فرم ورود معتبر هدایت می‌شود، اما کلید جلسه‌ای که قرار است استفاده شود توسط مهاجم تأمین می‌شود. پس از احراز هویت، مهاجم می‌تواند از کلید جلسه شناخته‌شده برای سرقت جلسه استفاده کند.
+- **استراق سمع(Session sidejacking)**: در این روش نفوذگر از طریق packetهای TCP/IP اطلاعات رد و بدل شده را به روش استراق سمع (معمولاً در شبکه‌های بیسیم) دریافت و از آن کلید جلسه را استخراج می‌کند.
+![image](https://github.com/user-attachments/assets/0c9e2a8d-e69f-4af1-b5a3-29db47242cc7)
+
+
+# روش‌های جلوگیری از session hijacking:
+تهدید سرقت جلسه به دلیل محدودیت‌های stateless بودن پروتکل HTTP وجود دارد. کوکی‌ها راهی برای غلبه بر این محدودیت‌ها و اجازه دادن به برنامه‌های وب برای شناسایی سیستم‌های کامپیوتری فردی و ذخیره‌سازی وضعیت جاری جلسه، مانند خرید شما در یک فروشگاه آنلاین، هستند.
+
+برای کاربران عادی ، پیروی از برخی قوانین ابتدایی امنیت آنلاین می‌تواند به کاهش خطر کمک کند، اما از آنجا که سرقت جلسه با بهره‌برداری از مکانیزم‌های اساسی که توسط اکثریت برنامه‌های وب استفاده می‌شود، عمل می‌کند، هیچ روش محافظتی واحد و قطعی وجود ندارد. با این حال، با سخت‌کردن جنبه‌های مختلف ارتباطات و مدیریت جلسه، توسعه‌دهندگان و مدیران سیستم می‌توانند خطر دستیابی مهاجمان به یک توکن جلسه معتبر را به حداقل برسانند. در ادامه به برخی از این روش‌ها می‌پردازیم:
+- استفاده از HTTPS اطمینان حاصل می‌کند که تمامی ترافیک جلسه با رمزنگاری SSL/TLS محافظت شود. این کار مانع از آن می‌شود که مهاجم بتواند شناسه جلسه را به صورت متن ساده رهگیری کند، حتی اگر ترافیک قربانی را نظارت کند. به‌طور ایده‌آل، از HSTS (HTTP Strict Transport Security) استفاده می‌شود تا اطمینان حاصل شود که تمامی ارتباطات به‌طور پیش‌فرض رمزنگاری شده هستند.
+- ویژگی HttpOnly را با استفاده از هدر Set-Cookie تنظیم می‌شود تا از دسترسی به کوکی‌ها توسط اسکریپت‌های سمت کلاینت جلوگیری شود. این کار از حملات XSS و سایر حملاتی که به تزریق جاوااسکریپت در مرورگر وابسته‌اند، جلوگیری می‌کند. همچنین مشخص کردن پرچم‌های امنیتی کوکی Secure و SameSite نیز برای امنیت بیشتر توصیه می‌شوند.
+- فریم‌ ورک‌های وب مثل OWASP یا Spring security مکانیزم‌های تولید و مدیریت شناسه جلسه امن و تست‌شده‌ای را ارائه می‌دهند.
+- باز تولید کلید جلسه بعد از اهراز هویت اولیه باعث می‌شود که کلید جلسه بلافاصله پس از احراز هویت تغییر کند، که حملات تثبیت جلسه را خنثی می‌کند – حتی اگر مهاجم شناسه جلسه اولیه را بداند، قبل از استفاده از آن بی‌فایده می‌شود.
+
+در ادامه به بیان یک مثال عملی ساده از چگونگی جلوگیری از session hijacking با توجه به مطالب گفته شده می‌پردازیم:
+# سناریو:
+شما در حال ساخت وب سایتی هستید که در آن کاربران قابلیت log in کردن دارند و تصمیم دارید از اطلاعات session آن‌ها محافظت کنید:
+## استفاده از HTTPS (SSL/TLS):
+وب سرور خود را با استفاه از HTTPS پیکره‌بندی کنید. با این کار تمام داده های مبادله شده بین مرورگر کاربر و سرور شما رمزگذاری می شود:
+```yml
+# Nginx SSL Configuration Example
+server {
+    listen              443 ssl;
+    server_name         www.example.com;
+    ssl_certificate     www.example.com.crt;
+    ssl_certificate_key www.example.com.key;
+    ssl_protocols       TLSv1.2 TLSv1.3;
+    ssl_ciphers         HIGH:!aNULL:!MD5;
+    ...
+}
+```
+## باز تولید شناسه نشست پس از log in:
+پس از اینکه کاربر با موفقیت وارد شد شناسه نشست را مجددا تولید کنید:
+```yml
+session_start();
+session_regenerate_id();
+```
+## قرار دادن پرچم‌های HTTPOnly و Secure هنگام ساخت Session cookie:
+روش‌های مختلفی برای انجام این کار وجود دارد. در این مثال نحوه پیکره بندی از طریق Tomcat نمایش داده شده است. در فایل context.xml داخل META-INF, این attribute را وارد نمایید:
+```yml
+<Context useHttpOnly="true">
+    <!-- Other configurations -->
+</Context>
+```
+در صورتیکه وب سرور خود را با استفاه از HTTPS پیکره‌بندی کرده باشید(قسمت اول مثال) پرچم Secure به صورت خودکار برای کوکی‌ها فعال می‌شود.
+
+با انجام تکنینک‌های فوق شما می‌توانید به میزان قابل توجهی تهدید session hijacking را در اپلیکیشن تحت وب خود کاهش دهید.
+
+# مراجع:
+- https://www.invicti.com/blog/web-security/session-hijacking/
+- https://nginx.org/en/docs/http/configuring_https_servers.html
+- https://www.php.net/manual/en/session.configuration.php#ini.session.cookie-secure
+- https://medium.com/@yadav-ajay/using-httponly-and-secure-cookies-on-web-servers-how-to-do-it-52ccf0eabfb4
+- https://en.wikipedia.org/wiki/Session_hijacking
+- https://fa.wikipedia.org/wiki/%D9%86%D8%B4%D8%B3%D8%AA%E2%80%8C%D8%B1%D8%A8%D8%A7%DB%8C%DB%8C#XSS
+
+
+

Session-hijacking-prevention/Video.md

@@ -0,0 +1,2 @@
+ویدیو مربوط به ارائه در لینک زیر قرار دارد:
+https://drive.google.com/drive/folders/1Ppm_sO7rA5mf2RIFRjJvhvg9hkdlzEUZ?usp=sharing