افشای اطلاعات حساس Sensitive Data Exposure

A3 2017
افشای اطلاعات حساس Sensitive Data Exposure
بردار حمله
App.Specific
قابلیت بهره برداری : 2

مهاجمان بجای حمات مخفیانه به صورت مستقیم، اقدام به سرقت کلیدها، اجرای حمات مرد میانی، یا سرقت اطلاعات رمز نشده سمت سرور یا کاربر، هنگام انتقال اطلاعات میً کنند. برای مثال مرورگر. معمولا یک حمله دستی لازم است. قبلا بانک های داده رمز عبور بازیابی شده باید توسط GPU ها مورد حمله force brute قرار می گرفت.

ضعف امنیتی
شیوع : 3
قابلیت تشخیص : 2

در طول چند سال گذشته این به یکی از حمات رایج پرآسیب تبدیل شده است. بزرگترین اشتباه رایج هم رمز نکردن اطلاعات حساس است. برای اطلاعات در حال انتقال، ضعف های سمت سرور به راحتی قابل تشخیص هستند.\\\\\\\\\\\\\\\\r\\\\\\\\\\\\\\\\n

تاثیرات
فنی : 3
تجاری ؟

یک شکست امنیتی عموما تمامی داده هایی که باید محافظت شوند را به خطر می اندازد. به طور معمول، این اطلاعات شامل اطلاعات شخصی حساس )PII )مانند پرونده های بهداشتی، اعتبارنامه، اطلاعات شخصی و کارت های اعتباری است که اغلب نیاز به حفاظت بر اساس قوانین یا مقرراتی مانند GDPR اتحادیه اروپا یا قوانین حفظ حریم خصوصی محلی دارند.

شناسایی آسیب پذیری

ولین نکته این است که نیازهای حفاظت از داده ها در هنگام انتقال و ثابت مشخص شود. به عنوان مثال، رمزهای عبور، شماره کارت اعتباری، پرونده های بهداشتی، اطلاعات شخصی و اسرار تجاری، حفاظت بیشتری نیاز دارند، به ویژه اگر داده ها تحت قانون حریم خصوصی قرار بگیرند، برای مثال مقررات حفاظت کلی اطلاعات اتحادیه اروپا )GDPR )یا مقررات، مانند حفاظت از اطلاعات مالی مانند :اطلاعاتی چنین برای. PCI Data Security Standard PCI DSS
* آیا داده ها به شکل رمز نشده ارسال شده اند؟ این مربوط به پروتکل هایی مانند ،HTTP SMTP و FTP است به ویژه ترافیک اینترنتی خارجی خطرناک است. تمام ترافیک داخلی را بررسی کنید، به عنوان مثال بین balancer load ها، وب سرور ها، و یا سیستم های end-back.
* آیا داده های حساس به صورت کشف ذخیره می شوند، از جمله پشتیبان ها؟
* آیا الگوریتم رمزنگاری قدیمی یا ضعیف استفاده می شود؟
* آیا رمزگذاری اعمال نشده است، به عنوان مثال آیا هر کدام دستورالعمل های امنیتی یا هدر های امنیتی کاربر (مرورگر) از دست رفته است؟
* آیا عامل کاربر (مثال برنامه، مشتری پست الکترونیکی) تأییدیه گواهی سرور دریافت شده را تأیید نمی کند؟ 
* شناسه نشست در URL قابل مشاهده باشد. (مثل Rewriting URL)
* شناسه نشست پس از ورود موفق، تغییر نکرده باشد.
* شناسه های نشست تداوم نداشته باشند. نشست های کاربر یا توکن های احراز هویت (به خصوص توکن های SSO on-sign Single )در هنگام خروج از سیستم یا عدم فعالیت در بازه ای از زمان، نامعتبر نمی شود

راه های جلو گیری

حداقل موارد زیر را دنبال کنید و مراجع را دنبال کنید:
* داده های پردازش شده، ذخیره شده، و یا ارسال شده توسط یک برنامه را طبقه بندی کنید.. بر اساس قوانین حریم خصوصی، الزامات قانونی یا نیازهای تجاری، داده های حساس را شناسایی کنید. طبق طبقه بندی، کنترل ها را اعمال کنید.
* در صورت عدم نیاز، داده های حساس را ذخیره نکنید. در اسرع وقت آن را حذف کنید یا از توافق DSS PCI برای عالمت گذاری یا حتی ناقص سازی استفاده کنید. داده هایی که ذخیره نمی شوند نمی توانند سرقت شوند.
* اطمینان حاصل کنید که همه اطلاعات حساس در حالت ذخیره را رمزگذاری کرده اید.
* اطمینان حاصل کنید از الگوریتم ها، پروتکل ها و کلیدهای استاندارد به روز و قوی در جای خود استفاده می شود. از مدیریت کلید مناسب استفاده کنید.
* رمزگذاری تمام داده های در حال انتقال با پروتکل های امن مانند TLS با رمزهای محرمانه بدون نقص (PFS ،)اولویت بندی رمز توسط سرور و پارامترهای امن. اعمال رمزگذاری با استفاده از .HTTP Security Transport Strict Security HSTS مانند هایی دستورالعمل
* برای پاسخ هایی که حاوی اطلاعات حساس هستند، ذخیره سازی (Caching)غیرفعال شود.
* رمزهای عبور را با استفاده از توابع هش قوی منطبق و هش salting با یک عامل کار (عامل تاخیر) مانند Argon2 و Scrypt و bcrypt یا BFKDF2 ذخیره کنید.
* به طور مستقل اثربخشی پیکربندی و تنظیمات را بررسی کنید.

مثال هایی از سناریوهای حمله

سناریو شماره 1 :یک برنامه شماره های کارت اعتباری را در پایگاه داده با استفاده از رمزگذاری خودکار پایگاه داده رمزنگاری می کند. با این حال، هنگام فراخوانی، این داده ها به صورت خودکار رمزگشایی می شود، و به یک نقص تزریق SQL اجازه می دهد شماره کارت اعتباری را در حالت کشف بازیابی کند.
سناریو شماره 2 :یک سایت از TLS برای تمام صفحات استفاده نمی کند و یا از رمزنگاری ضعیف پشتیبانی می کند. یک مهاجم ترافیک شبکه را شنود می کند )به عنوان مثال در یک شبکه بی سیم ناامن(، ارتباطات را از HTTPS به HTTP تنزل می دهد، درخواست های بین کاربر اصلی و سرور را قطع می کند، و کوکی نشست کاربر را سرقت می کند. مهاجم پس از آن از این کوکی استفاده می کند و نشست کاربر )احراز هویت شده( را دزدیده، به داده های شخصی کاربر دسترسی پیدا می کند یا آنها را تغییر می دهد. به جای موارد باال می تواند تمام داده های منتقل شده مثل دریافت کننده یک انتقال مالی را تغییر دهد.
سناریو شماره 3 :پایگاه داده رمز عبور از هش های unsalted یا ساده برای ذخیره کلمه عبور استفاده می کند. یک نقص آپلود فایل به مهاجم اجازه می دهد رمز عبور پایگاه داده را بازیابی کند. تمام هش های unsalted را می توان با یک جدول از هش های پیش محاسبه شده شکست. هش های تولید شده توسط توابع هش ساده یا سریع ممکن است توسط GPU ها شکسته شوند، حتی اگر از نوع salted باشند.

منابع
OWASP
OWASP Risk Rating Methodology
Article on Threat/Risk Modeling
External
ISO 31000: Risk Management Std
ISO 27001: ISMS
NIST Cyber Framework

جزییات بازدید : 12

تاریخ انتشار : 23 / مرداد / 1398

آشنایی با حملات افشای اطلاعات حساس یا Sensitive Data Exposure
حملات افشای اطلاعات حساس به‌عنوان یکی از گسترده‌ترین نوع حملات، زمانی رخ می‌دهد که کاربران بر اساس اعتمادی که به وب‌سایت و سرور آن دارند، اطلاعات و داده‌های خود را در یک وب‌سایت وارد می‌نمایند؛ اما زمانی که یک شکاف امنیتی در وب‌سایتی به وجود می‌آید، کاربران دچار شک و تردید در زمینه ورود اطلاعات خود می‌شوند.

قرار گرفتن در معرض، حملات افشای اطلاعات حساس، می‌تواند ناشی از حملات داخلی یا خارجی باشد. در حملات داخلی، یک کارمند ناراضی به‌عنوان یک تهدید بالقوه که دسترسی به اطلاعات حساس شرکت و کاربران را دارد می‌تواند به‌عنوان تهدیدی خطرناک به‌حساب آید. ازاین‌رو ذخیره‌سازی داده‌ها به‌صورت ابری یا Cloud، می‌تواند یک گزینه مناسب برای ذخیره‌سازی اطلاعات حساس باشد.

حملات افشای اطلاعات حساس، زمانی رخ می‌دهد که یک برنامه کاربردی وب، به‌صورت کامل نتواند از اطلاعات حساس محافظت نماید و به کاربران غیرقانونی و یا هکرها اجازه سرقت اطلاعات را می‌دهد.

روش‌های جلوگیری از حملات افشای اطلاعات حساس:
رمزگذاری داده‌ها و تعریف سطح دسترسی‌ها:
رمزنگاری اطلاعات و داده‌های حساس در صورت ذخیره‌سازی و یا نقل و انتقالات در بستر شبکه، یکی از مهم‌ترین موضوعات قابل‌بحث در زمینه‌ی امنیت می‌باشد؛ و برای جلوگیری از افشای اطلاعات حساس نیازمند رمزنگاری مبتنی بر کلید هستیم. مورد دیگر تعیین سطح دسترسی به داده‌هایی است که نیازمند حفاظت بیشتری هستند. داده‌ها و اطلاعات برای کاربران باید دارای سطح دسترسی‌های خاصی باشد تا کاربران غیرقانونی و هکرها نتوانند به این داده‌ها دسترسی داشته باشند.

دروازه تائید هویت:
استفاده از نشست‌های پروتکل HTTPS، باعث می‌شود تا یک ارتباط امن را فراهم آورد. استفاده از تکنولوژی‌های پیشرفته و دارای استاندارد امنیتی، مانند SSL و یا TLS، کمک می‌نمایند تا بتوانیم تمام داده‌های بین مرورگر و سرور وب را رمزگذاری کرده و سطح قابل توجه ای از امنیت را برای جلوگیری از افشای اطلاعات حساس فراهم آوریم.

جلوگیری از حملات رمز عبور:
استفاده از رمزهای عبور ضعیف، به‌عنوان یکی از شایع‌ترین نقص‌های امنیتی شناخته می‌شود. با استفاده از الگوریتم‌های هش کردن رمز عبور، نیازمند آن هستیم تا از گذرواژه‌های قوی استفاده نماییم و در بازه‌های زمانی مختلف این رمزهای عبور را تغییر دهیم.

ارزیابی ریسک به‌صورت منظم:
میزان ریسک در وب‌سایت‌ها و وب سرورها ممکن است با تغییر فرآیندهای کسب‌وکار تغییر نمایند؛ بنابراین لازم است تا به‌صورت منظم، سیستم امنیتی و دفاعی برای مقابله با هرگونه تهدید احتمالی، ارزیابی و به‌روزرسانی گردد.

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


انواع حملات افشای اطلاعات حساس یا Sensitive Data Exposure
در دسته‌بندی حملات افشای اطلاعات حساس می‌توان چهار دسته‌بندی کلی را مورد بررسی قرارداد که در ادامه به آن‌ها اشاره‌شده است.

نشت اطلاعات ناشی از پاک کردن حافظه ناکافی
حفاظت ناکافی از کلیدهای رمزنگاری
وجود رمزهای عبور Clear-Text در فایل‌های پیکربندی
نبود یکپارچگی در محافظت از داده‌های ذخیره‌شده کاربر
در ادامه موضوع حملات افشای اطلاعات حساس، می‌توان انواع مختلفی از حملات را نام برد؛ که می‌تواند موجب افشای اطلاعات کاربران شود. در موارد زیر به تعدادی از انواع حملات افشای اطلاعات حساس پرداخته‌شده است.

۱- حملات Base64 Encoding (Secret)
در ابتدای بیان این نوع حمله، نیاز است تا با تفاوت Encoding،Encryption و Hashing آشنا شویم.

Encoding
هدف از Encoding تبدیل کردن داده‌ها، به صورتی است که سیستم‌های دیگر نیز بتوانند از آن بهره‌برداری نمایند و هدف آن مخفی کردن داده‌ها نبوده و نخواهد بود. Encode کردن، با استفاده از یک قالب خاص، اطلاعات و داده‌ها را به شکل دیگری تبدیل می‌نماید و به‌راحتی قابل‌برگشت می‌باشد. برای بازگرداندن متن‌ها Encode شده به حالت اولیه، به کلید رمزنگاری خاصی نیاز نیست و تنها به الگوریتمی که با آن Encode را انجام داده‌ایم، نیاز خواهیم داشت؛ مانند Unicode،ASCII،Base64 و …

Encryption
هدف از رمزنگاری یا Encryption، تبدیل اطلاعات و داده‌ها به نحوی است که از معرض دید و فهم دیگران مخفی بماند. در این روش، اطلاعات و داده‌ها به صورتی تبدیل می‌شوند که طرفین نیازمند استفاده از الگوریتم‌ها و کلیدهای خاص برای رمزگشایی هستند؛ مانند RSA و Blowfish و AES و …

Hashing
هدف از هش کردن، اطمینان از درستی و تمامیت اطلاعات و داده‌ها می‌باشد. در عملیات Hashing هدف آن است که اگر حتی یک بیت داده تغییر نماید، تغییرات مشخص شود. در عملیات Hashing، یک ورودی ثابت همیشه یک خروجی ثابت، تولید می‌نماید و همچنین، ورودی‌های مختلف، نباید خروجی یکسانی تولید کنند. دستیابی به داده‌های خروجی، با استفاده از داده‌های ورودی، غیرممکن و یا بسیار سخت می‌باشد. از Hashing برای عملیات احراز هویت داده‌ها، استفاده می‌شود؛ مانند MD5 و SHA-3 و SHA256 و …

حال که با تفاوت این سه نمونه از دست‌کاری داده‌ها آشنا شدیم، به بررسی حملات Base64 Encoding می‌پردازیم. این نوع از حملات غالباً به علت، عدم طراحی و برنامه‌نویسی صحیح، به وجود می‌آید. در حملات Base65 Encoding یا همان Encoding به روش Base64، برنامه‌نویس یا طراح، بجای استفاده از رمزنگاری یا Encrypting پسوردها و یا URL ها، تصمیم می‌گیرد که از Encoding استفاده نماید. عمل Encoding در رمزهای عبور و یا URL ها، باعث می‌شود، زمانی که هکر بتواند به پایگاه داده یا اطلاعات وب‌سایت دسترسی پیدا نماید، رمزهای عبور را Decode نموده و به‌راحتی به داده اصلی دسترسی پیدا کند؛ بنابراین، برنامه‌نویس یا طراح، باید در مکان‌هایی که داده‌های حساس و حیاتی نگهداری یا مورد نمایش هستند، از رمزنگاری یا Encrypting بجای Encoding استفاده نماید.


۲- حملات BEAST/CRIME/BREACH Attacks
این سه نوع از حمله، علیه پروتکل ارتباطی SSL/TLS می‌باشد؛ که در ادامه به هرکدام از آن‌ها خواهیم پرداخت.

حملات SSL/TLS: بخش اول- حملات BEAST Attack
عبارت BEAST مخفف عبارت Browser Against SSL/TLS می‌باشد. این نوع حمله، یک از انواع حملات سمت مشتری یا Client Side است. در این نوع حمله پیش‌نیازهایی وجود دارد که عبارت‌اند از:

SSL فعال‌شده وب سرور، باید نسخه‌ی SSL 3.0 یا پایین‌تر و یا دارای TLS 1.0 باشد.
مهاجم باید بتواند محتوایش را با محتوای SSL مخلوط کند.
مهاجم یا هکر باید حمله‌ی یک مردمیانی (Man in The Middle) را اجرا کند تا بتواند ترافیک SSL را مشاهده کند.
این نوع حمله تنها در بلوک رمزهایی مانند DES و AES کار می‌کند.
برای جلوگیری از این نوع حملات می‌توان از TLS 1.1 و یا TLS 1.2 استفاده نمود و اگر از نسخه پایین‌تر TLS و یا SSL بر روی سرور استفاده می‌شود، از یک رمز جریان مانند RC4 نیز استفاده شود.

حملات SSL/TLS: بخش دوم- حملات CRIME Attack
عبارت CRIME مخفف عبارت Compression Ratio Info-Leak Made Easy می‌باشد. این نوع از حمله، برای استخراج توکن های نشست محافظت‌شده، توسط پروتکل SSL/TLS استفاده می‌شود. حمله‌ی CRIME از ویژگی فشرده‌سازی داده‌ی SSL و TLS بهره می‌گیرد. باید توجه داشت که هیچ‌یک از نسخه‌های TLS به این نوع از حملات ایمن نیست و باید حالت فشرده‌سازی را برای SSL/TLS غیرفعال نمود.

حملات SSL/TLS: بخش سوم- حملات BREACH Attack
عبارت BREACH مخفف عبارت Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext می‌باشد. حملات BREACH بر اساس اکسپلویت امنیتی CRIME ساخته‌شده است و تفاوت‌های بسیار ظریفی با همدیگر دارند. حمله‌ی BREACH، فشرده‌سازی را برای استخراج داده‌ها از یک کانال ارتباطی SSL/TLS مورد ارزیابی قرار می‌دهد. هرچند که تمرکز این نوع حمله، بر فشرده‌سازی SSL/TLS نیست، بلکه بیشتر تمرکز این نوع حمله، بر فشرده‌سازی HTTP است. این حمله تلاش می‌کند تا از پاسخ‌های HTTP فشرده‌شده و رمزنگاری‌شده به‌جای درخواست‌ها استفاده نماید. لازم است که بدانیم فشرده‌سازی پاسخ HTTP، فقط برای بدنه یا Body اجرا می‌شود نه برای هدر یا Header. به‌صورت کلی چون به‌راحتی نمی‌توان فشرده‌سازی HTTP را خاموش نمود، حملات BREACH بسیار قدرتمندتر از حملات CRIME خواهند بود. برای جلوگیری از حملات BREACH می‌تواند دستورات زیر را بکار برد.

غیرفعال نمودن فشرده‌سازی HTTP
جداسازی کلیدها یا secret ها از ورودی‌های کاربر
تصادفی سازی در هر درخواست کاربر
محدودسازی سرعت درخواست‌ها
نتیجه‌گیری سه نوع حمله‌ای که علیه SSL/TLS صورت می‌گیرد، نشان می‌دهد که افزایش حملات به این پروتکل ارتباطی در حال افزایش است و نیازمند آن هستیم تا آگاهی‌های لازم در جهت شناخت بیشتر این نوع حملات را داشته و بتوانیم اقدامات کاهشی را در مقابل آن انجام دهیم و سعی در جلوگیری از افشای اطلاعات حساس داشته باشیم.

۳- حملات Clear Text HTTP (Credentials)
در این نوع از حملات، زمانی که کاربر، پسورد یا اطلاعات حیاتی خود را در درخواست‌ها ارسال می‌نماید، بدون توجه به پروتکل ارتباطی، خواهد دید که درخواست‌ها از طریق HTTP ارسال می‌گردند. زمانی که یک درخواست به‌صورت واضح و از طریق پروتکل HTTP ارسال می‌گردد، هکر یا مهاجم می‌تواند با شنود یا ضبط ترافیک بین کاربر و سرور اطلاعات را مشاهده نماید؛ بنابراین استفاده از متن واضح یا Clear Text و ارسال کردن اعتبارنامه‌ها با استفاده از پروتکل HTTP باعث نشت اطلاعاتی و افشای اطلاعات حساس شده و اعتبارنامه‌های کاربر در معرض خطر قرار خواهند گرفت.

۴- حملات Heart Bleed Vulnerability
حملات Heart Bleed یا خونریزی قلبی، یک شکاف امنیتی در کتابخانه رمزنگاری متن‌باز SSL است که به هکر اجازه خواندن حافظه‌ی کامپیوتری که در حال اجرای این نرم‌افزار است را می‌دهد. این شکاف امنیتی به هکر اجازه می‌دهد تا کلیدها خصوصی SSL قربانی را بازیابی نماید. این باگ امنیتی به دلیل یک اشتباه کد نویسی OpenSSL به وجود آمده است. خواندن بخش تصادفی از حافظه سرور، می‌تواند باعث شود، اطلاعات حساسی در اختیار هکر قرار گیرد و در پی آن امنیت کاربران و سرورها به خطر بیافتد. برای جلوگیری و شناسایی این نوع حملات به مدیران وب سرورها توصیه می‌شود تا از نسخه‌های بدون باگ OpenSSL استفاده نمایند.

۵- حملات Host Header Attack (Reset Poisoning)
در وب سرورهای اشتراکی یا هاست های اشتراکی، از یک IP Valid برای میزبانی چندین وب‌سایت یا برنامه کاربردی وب استفاده می‌شود. زمانی که وب سرور اشتراکی درخواست HTTP را دریافت می‌نماید، بر اساس بخش هدر درخواست تشخیص می‌دهد که کدام وب‌سایت یا برنامه کاربردی باید پردازش آن درخواست را انجام دهد. باید توجه داشت که هر برنامه کاربردی وب یا وب‌سایتی که توسط یک IP میزبانی می‌شود را میزبان مجازی می‌گوییم. درزمانی که هکر یا مهاجم بتواند هدر میزبان را دست‌کاری کند چه اتفاقی خواهد افتاد؟

برای پاسخ به سوال بالا باید بگوییم که اکثر وب سرورها به‌گونه‌ای پیکربندی‌شده‌اند که درخواست‌های با هدر میزبان نامعلوم را به اولین میزبان مجازی در لیست منتقل می‌کنند.

یک‌راه دیگر، انتقال هدر میزبان خودسرانه (Arbitrary)، استفاده از هدر X-Forwarded-Host می‌باشد. هدر X-Forwarded-Host باعث می‌شود تا تنظیمات هدر میزبان (Host Header) را بازنویسی نماید.

دو نوع حمله اساسی در حملات هدر میزبان، نهفته است که باید با آن‌ها آشنا بود.

مسمومیت کش وب‌سایت
در این روش هکر یا مهاجم، کش وب‌سایت را دست‌کاری کرده و سعی بر آن دارد تا محتوای مسموم خود را در کش وب‌سایت قرار دهد تا هرکسی که درخواستی به سمت وب‌سایت ارسال می‌کند را مسموم نماید.

سوءاستفاده از کانال‌های جایگزین برای انجام عملیات حساس، مانند بازیابی رمز عبور
در وب‌سایت‌ها، یکی از راه‌های معمول برای بازیابی رمز عبور استفاده از توکن های مخفی می‌باشد. زمانی که مدیر سایت یا کاربران قصد بر بازیابی رمز عبور را دارند، ایمیل خود را وارد نموده و سپس وب‌سایت در پاسخ به درخواست آن‌ها، یک ایمیل را ارسال می‌نماید. این ایمیل شامل یک لینک است که دارای توکن مخفی بوده و برای بازیابی رمز عبور مورداستفاده قرار می‌گیرد. حال اگر برنامه کاربردی وب یا همان وب‌سایت از هدر میزبان برای بازیابی رمز عبور استفاده نماید، هکر می‌تواند لینک بازیابی رمز عبوری که برای قربانی ارسال می‌شود را مسموم نماید. سپس اگر قربانی بر روی آن لینک بازیابی رمز عبور مسموم شده کلیک نماید، هکر می‌تواند رمز عبور قربانی را بازیابی کند.

برای مقابله با حملات Host Header Attach باید به هدر میزبان اعتماد نداشته باشیم و درصورتی‌که از هدر میزبان برای شناسایی مکان سرور استفاده می‌شود، باید از لیست سفید (Whitelist) نام‌های هاست (Hostnames) مجاز استفاده کنیم.

۶- حملات HTML5 Web Storage (Secret)
به‌صورت کلی می‌توان گفت که Web Storage یا همان DOM Storage مجموعه‌ای از API ها بوده که در تلاش هستند تا داده‌های سمت کاربر را بر روی مرورگر ذخیره کنند. این تکنولوژی با معرفی HTML 5 پا به عرصه گذاشت و برای طراحان معرفی گردید. Web Storage ها از کوکی‌ها سریع‌تر بوده و برخلاف کوکی‌ها بر روی مرورگر کاربر ذخیره می‌شوند و از شبکه منتقل نمی‌شوند.

ازآنجایی‌که ذخیره‌سازی Web Storage دارای فواید خود می‌باشد اما ممکن است باعث مشکلات امنیتی گردد. هنگامی‌که اطلاعات حساس و حیاتی در Local Storage ذخیره می‌شوند، هکر می‌تواند با اجرای یک کد جاوا اسکریپت در وب‌سایت، تمامی داده‌هایی که در Local Storage ذخیره‌شده‌اند را بازیابی نماید و سپس آن را به دامنه موردنظر خود ارسال کند (با استفاده از حملات XSS).

۷- حملات POODLE Vulnerability
آسیب‌پذیری Poodle مخفف عبارت Padding Oracle On Downgraded Legacy Encryption می‌باشد. این آسیب‌پذیری توسط تیم امنیتی گوگل برای اولین بار منتشر شد. این آسیب‌پذیری از یک ضعف ساختاری در پروتکل SSLv3 است و از مشکلات پیاده‌سازی پروتکل نیست و تنها راه برطرف سازی این شکاف امنیتی، غیرفعال کردن کامل پروتکل SSLv3 می‌باشد. این آسیب‌پذیری به هکر اجازه می‌دهد که از محتوای حساس و حیاتی کاربر در حین یک اتصال SSL، رمزگشایی نموده و به‌عنوان نمونه به اطلاعات هویتی در کوکی‌ها دسترسی داشته باشد.

۸- حملات SSL 2.0 Deprecated Protocol
این حفره امنیتی که در OpenSSL کشف‌شده با عنوان DROWN نیز نام‌گذاری گردیده است. این حمله به افشای اطلاعات حساس و حیاتی ارتباطات HTTPS، شامل رمزهای عبور و اطلاعات حساب‌های بانکی و غیره منجر به می‌شود. این حمله باعث رمزگشایی جلسه‌ی TLS می‌گردد. این آسیب‌پذیری یک حمله‌ی بین پروتکلی است که از ضعف پیاده‌سازی SSL v2 بهره می‌برد و می‌تواند نشست‌های TLS به‌دست‌آمده از کاربران را به‌صورت غیرفعال ترجمه نماید. برای برطرف کردن این آسیب‌پذیری به کاربران و یا مدیران توصیه می‌شود تا از نسخه‌های امن OpenSSL استفاده نمایند و همچنین مطمئن شوید که SSL v2 غیرفعال شده است و یا در فایروال ترافیک‌های SSL v2 را فیلتر نمایید.

۹- حملات Insufficient Transport Layer Protection
حملات حافظت نامناسب از لایه انتقال، اجازه می‌دهد تا ارتباطات با شخص ثالث غیر قابل‌اطمینان گردد و اطلاعات و داده‌های حساس در معرض خطر قرار گیرند. وب‌سایت‌ها غالباً از SSL/TLS برای امن سازی و رمزنگاری لایه انتقال استفاده می‌کنند. درصورتی‌که پیکربندی مناسبی برای استفاده از SSL/TLS انجام نگردد، ممکن است به نفوذ و درنتیجه افشای اطلاعات حساس منجر شود. هنگامی‌که لایه انتقال، رمزنگاری نگردد؛ تمامی ارتباطات میان سرویس‌دهنده و سرویس‌گیرنده به‌صورت Plaintext ارسال می‌گردد و هکر می‌تواند، اطلاعات را ضبط یا بازرسی کرده و یا حتی اطلاعاتی را تزریق و یا Redirect نماید و یا یک حمله‌ی مردمیانی را پیاده‌سازی کند. برای پیشگیری از افشای اطلاعات حساس نیاز است تا فقط از رمزنگاری‌های قدرتمند استفاده نمود و خدماتی به مشتریان ارائه دهیم که درخواست‌ها با رمزنگاری ضعیف برای مشتری ارسال نگردد.

۱۰- حملات Text Files (Accounts)
گاهی اوقات در بعضی از وب‌سایت‌ها مشاهده‌شده است که فایل‌های با پسوند txt ی وجود دارند که شامل فهرستی از اکانت ها و یا اکانت به همراه پسورد است. این نوع اشتباهات که توسط طراحان و برنامه‌نویسان صورت می‌گیرد باید مورد ارزیابی قرار گیرد تا مشکلات امنیتی را به همراه نداشته باشد. افشای اطلاعات حساس در فایل‌های txt، بسیار در سطح وب فراوان است و همیشه بعد از طراحی و پیاده‌سازی وب‌سایت‌ها، مهندسین طراح باید فایل‌های txt را موردبررسی قرار دهند تا شکاف امنیتی رخ نداده و اطلاعات کاربران به سرقت نرود.