دارپا هنوز از وب به‌عنوان سلاح استفاده می‌کند

همه می‌دانند اینترنت در اصل یکی از پروژه‌های نظامی ایالات متحده بوده است. استفن جی لوکاسیک، نایب‌رئیس و رئیس دارپا در مورد علت ساخت آرپانت توضیح می‌دهد:

هدف این پروژه، استفاده از فناوری‌های جدید کامپیوتری در جهت نیازهای نظامی و کنترل تهدید‌های هسته‌ای، کنترل پایدار نیروهای هسته‌ای ایالات متحده و بهبود تصمیم‌گیری مدیریتی و تاکتیکی ارتشی بود.

شاید این داستان‌ها برای برنامه‌نویسان جوان که پس از ۱۹۸۹ متولدشده‌اند، به‌نظر عجیب یا حتی شگفت‌انگیز برسد؛ به‌ویژه اگر اهل ایالات متحده یا اتحاد جماهیر شوروی نبوده باشید، تشخیص دوست و دشمن برایتان دشوار می‌شود. اروپا از هر دو طرف (شرق و غرب) با دو پروپاگاندای قدرتمند احاطه شده بود و هنوز هم آثار این جنگ فرهنگی باقی مانده است.

پروتکل اینترنت به‌اندازه‌ای مفید بود که برای ساخت مجموعه‌ پروتکل‌های سطح بالاتر به‌کار رفت: در درجه‌ی اول TCP/IP و UDP/IP و سپس پروتکل‌های کاربردی مثل DNS (یک نوع دفتر تلفن سلسله‌مراتبی)، FTP (انتقال فایل بهینه) و SMTP (ایمیل) برای برطرف کردن نیازهای مشخص ساخته شدند.

سیستم نام دامنه‌

بر اساس تعریف آدرس IP شماره‌ای است برای فراخوانی کامپیوترها؛ به همین دلیل روی هر کامپیوتر، دفترچه‌های تلفنی ایجاد می‌شود و ابزارهایی برای جستجو در این دفترچه‌ها درنظر گرفته می‌شوند. شاید تشبیه DNS به یک دفترچه‌ی سلسله‌مراتبی تلفن عجیب به‌نظر برسد؛ اما وقتی بدانید که این سرویس برای کمک به آدرس‌دهی و تحویل ایمیل طراحی شده است، درک این تعریف برایتان ساده‌تر می‌شود.

بااین‌حال، خیلی زود مشخص شد به‌روزرسانی دستی این دفترچه‌های تلفنی (کاملا توزیع‌شده) آزاردهنده، غیربهینه و پر از خطا است. مرکز اطلاعات شبکه‌ی مؤسسه‌ی پژوهشی استانفورد (NIC) بین دسامبر ۱۹۷۳ و مارس ۱۹۷۴ به‌عنوان منبع رسمی فایل‌های هاست اصلی درنظر گرفته شد. امروزه وجود چنین سیستم توزیع‌شده‌ای کمی عجیب است (باوجود نگرانی‌های مربوط به نقطه‌ی مستقل خطاها و پروتکل‌های یکپارچه)؛ اما SRI تقریبا به‌مدت یک دهه خدمات خوبی را به اینترنت ارائه داد.

زندگی در آن زمان، بسیار ساده بود: برای ارسال یک ایمیل UUCP به کاربری به‌نام giacomo که در سروری به‌نام tesio کار می‌کرد، فقط کافی بود مسیر سرور خود را با آدرس‌هایی مثل aserver!anotherserver!yetanotherserver!tesio!giacomo انتخاب کنید. در این عبارت aserver!anotherserver!yetanotherserver!tesio توالی مرتبی از سرورها برای اتصال و انتقال پیغام بود.

با رشد شبکه بین مارس و اکتبر ۱۹۸۲، سیستم نام دامنه‌ی مدرن طراحی شد و خیلی زود در سراسر دنیا توسعه یافت. اسامی هاستی که امروزه برای ایمیل، مرور وب، به‌روزرسانی‌های نرم‌افزاری و بسیاری از کارهای ضروری به‌کار می‌برید، در همین بازه‌ی زمانی متولد شدند. در این اثنا، ARPANET هنوز هم تحت کنترل ارتش ایالات متحده قرار داشت.

محدوده‌ی DNS Root

قدمت صفحه‌ی ویکی‌پدیا در DNS Root به ۱ آگوست ۲۰۰۳ بازمی‌گردد. این بخش به‌مدت دو سال عنوانی به‌نام اصول محدوده‌ی DNS root داشت اما در ژوئن ۲۰۰۵ حذف شد. مؤلف صفحه‌ی اصلی این صفحه این ویژگی را یک موضوع بسیار جذاب می‌دانست اما برای نوشتن در مورد آن تردید داشت. این بخش کاملا پیچیده است و نوشتن در مورد آن بدون دسته‌بندی منابع اصلی دشوار است؛ بنابراین به‌سختی می‌توان آن را با یک دیدگاه بی‌طرفانه نقد کرد. ویکی‌پدیا در این باره نوشته است:

سرورهای DNS برای عملکرد اینترنت ضروری هستند. این سرورها، ایستگاه‌های بالقوه‌ی خطا برای کل اینترنت هستند. به همین دلیل تعداد زیادی از سرورهای root در سراسر دنیا توزیع شده‌اند. نکته‌ی جالب اینجاست که از میان سیزده DNS Root ، ده Root تحت مدیریت سازمان‌های آمریکایی قرار داشتند. Root zone توسط Verisign توزیع شده بود که مدیریت مستقیم a.root-server.net و j.root-server.net را برعهده داشت (هر دو وب‌سایت با مجوز منقضی SSL روی HTTPS قرار گرفته‌اند). مسلما برای کاهش خطر حملات DDoS، این سرورها نباید فیزیکی باشند؛ اما کلاستر سرورها از طریق آدرس‌دهی انی‌کست (همه‌پخشی) در سراسر جهان توزیع شدند.

از تاریخ ۳۰.۷.۲۰۱۸، سیستم root server شامل ۹۳۱ نماینده است که توسط ۱۲ اپراتور مستقل root server اداره می‌شوند

در یک نگاه واکنش شبکه نسبت به حملات را می‌توان دید؛ اما اگر همین صفحه را تقسیم کنید و بر اساس ملیت سازمان ارائه‌دهنده‌ی سرور، یک پرچم کوچک را برای هر سرور درنظر بگیرید، به یک نقشه‌ی مفیدتر دست خواهید یافت.

سرورهای Root تحت مدیریت سازمان‌های ژاپنی (چپ)، اروپا (مرکز) و ایالات متحده‌ی آمریکا (راست)

در اینجا Great Firewall یا دیوار آتش بزرگ، معنای کاملا متفاوتی را به‌خود می‌گیرد. از ۹۳۱ سرور روت، ۸۱۰ سرور تحت کنترل ایالات متحده هستند. ازنظر تئوری، ایالات متحده می‌تواند ارزان‌ترین Ddos تاریخ را بر اساس قانون انکار موجه (plausible deniability) ایجاد کند؛ به‌موجب این قانون که در دهه‌ی ۱۹۶۰ توسط سازمان سیا به‌‌کار برده شد، این سازمان از ارائه‌ی برخی اطلاعات به مقامات (مثلا رئیس جمهور) درباره‌ی برخی فعالیت‌های بدنام خود، خودداری می‌کرد. برای شبیه‌سازی حمله‌ی موفق DDoS می‌توان سرورها را در یک منطقه خاموش کرد تا کل DNS Rootهای دیگر تحت ترافیک قانونی از هم بپاشند.

ورود به وب

در مارس ۱۹۸۹، جوانی به‌نام تیم برنرز لی، طرح یک پیشنهاد برای سیستم مدیریت اطلاعاتی را به رئیس خود مایکل سندال می‌دهد. «مبهم ولی هیجان‌انگیز»، کلماتی که سندال روی طرح پیشنهادی او نوشت و به برنرز لی اجازه داد کار خود را ادامه دهد. دو سال بعد، اولین مرورگر و اولین سرور وب ساخته شدند. URI (شناسه‌ی منبع جهانی)، HTML (زبان نشانه‌گذاری ابَرمتن) و HTTP (پروتکل انتقال ابرمتن)، تنها راه‌حل‌های موجود برای مشکلات آن زمان نبودند؛ اما توانستند تا اندازه‌ای در رقابت بین پروتکل‌ها برنده شوند و در سطح گسترده‌ای تطبیق داده شوند.

تا معرفی SSL در ۱۹۹۴ توسط Netscape Navigator، هیچ راهی برای احراز هویت یک سرور HTTP یا انتقال محرمانه‌ی داده‌ها وجود نداشت؛ اما این مسئله مشکل‌ساز نبود زیرا HyperTextها یا ابرمتن‌ها بیشتر واسطه‌های فرهنگی بودند تا محیط‌هایی برای بازار و کسب‌وکار. با وجود بعضی نواقص فنی، این پروتکل و زبان بسیار ساده بودند و موفقیت آن‌ها به‌قدری وسیع بود که مرورگرهای زیادی توسعه یافتند.

سیر زمانی مرورگرهای وب

جنگ مرورگرها

در راستای اهداف و منشأ نظامی اینترنت، جنگ‌های وب هم آغاز شده بودند: جنگ مرورگرها. جنگ مرورگرها شامل یک مجموعه رقابت‌های پیچیده‌ی تجاری بود (موضوع‌ها و مطالبی که به‌اندازه‌ی کتاب‌ها ارزش‌ داشتند و دارای پیچ‌وتاب و داستان، اسب‌ها تروجان و هک‌های قوی بودند).

با وجود تمام این رقابت‌ها در اواخر سال ۲۰۰۴ تنها یک مرورگر مستقل توانست برنده شود. این مرورگر اینترنت اکسپلورر ۶ بود که ۹۲ درصد از وب را تحت پوشش خود قرار داد. در آن زمان فناوری‌هایی مثل XHTML، CSS، XSLT، XSD، Atom و RSS در عرضه‌ی توسعه‌ی وب رونق پیدا کرده بودند. ایده‌ی XHTML توزیع آسان محتوای وب ماشینی بود به‌طوری‌که برای انسان هم به‌راحتی قابل‌نوشتن باشد. با ورود CSS و XSL، جداسازی کامل نمایش و محتوا در نیمه‌ی راه خود قرار گرفت. با XSL-FO امکان استخراج محتوا از صفحات وب و تولید گزارش‌های PDF از آن‌ها فراهم شد.

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

HTML5

HTML5 یک ‌زبان به‌اصطلاح چسبی برای طراحان وب و برنامه‌نویسان محسوب می‌شود که با مؤلفه‌هایی مثل تصاویر، پلاگین‌ها و اپلت‌های جاوا به تولید محتوای وب می‌پردازند. جاوا به‌عنوان یک زبان مؤلفه‌ای درنظر گرفته می‌شود که برنامه‌نویسان گران‌قیمت از آن استفاده می‌کنند؛ درحالی‌که برنامه‌نویس‌های چسبی (طراحان صفحات وب) معمولا با استفاده از جاوا اسکریپت به مونتاژ مؤلفه‌ها و خودکارسازی روابط می‌پردازند.

اما ناگهان در سال ۲۰۰۴، اپل، موزیلا و اپرا با XHTML تمایل خود به W3C و عدم تمایل به HTML را نشان دادند و حتی به نیازهای توسعه‌دهندگان وب بی‌اعتنایی کردند. آن‌ها برای حل مشکل WHATWG (مخفف گروه کاری فناوری برنامه‌ی ابرمتن وب) را ساختند. WHATWG انجمنی متشکل از افراد علاقه‌مند به HTML و فناوری‌های مرتبط با آن بود. به این صورت توانستند ۸ درصد وب را پوشش دهند. آن‌ها مفهوم Living Standards را معرفی کردند. Living Standards شامل مستنداتی است که ازنظر طراحی ناپایدارند و کسی نمی‌تواند به‌طور کامل آن‌ها را به‌روزرسانی کند.

این گروه در سال ۲۰۰۷، W3C را قانع کردند تا برای نسخه‌ی فعلی پیش‌نویس‌های ناپایدار و همان چیزی که امروزه به‌نام HTML5 شناخته می‌شود، بازاریابی کنند. HTML5 ربطی به HTML نداشت و بیشتر مربوط به جاوا اسکریپت بود. تا HTML4 وب یک ابرمتن (HyperText) بود. پروتکل و زبان‌های نشانه‌گذاری، عملکرد شفافی داشتند. هدف HTML4، ارائه‌ی متن‌های مرتبط به مردم بود؛ مثل یک کتابخانه‌ی عمومی با تعداد زیادی مرجع میانی. با ظهور HTML5، وب به پلتفرمی برای پیاده‌سازی و توزیع نرم‌افزار تبدیل شد. تغییرات مثبت در زبان نشانه‌گذاری بسیار کم بودند. تنها تغییر قابل‌توجه، منسوخ شدن XHTML بود و حتی بسیاری در این مورد متعجب شدند.

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

و در نهایت جاوا اسکریپت به یک سلاح تبدیل شد...

کنارگذاشته‌شدن XHTML توسط W3C در سال ۲۰۰۷ تعجب بسیاری را برانگیخت. بسیاری از افراد، زیرساخت‌های خود را بر اساس XML/XHTML ساخته بودند. جاوا اسکریپت در HTML4 مشکلاتی داشت؛ اما در کل یک مورد جدی محسوب نمی‌شد. با ظهور HTML5، تعداد زیادی از مشکلات امنیتی آن آشکار شد.

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

یک سلاح دقیق

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

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

ورود به WebAssembly

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

جاوا اسکریپت حتی به‌عنوان یک سلاح هم مشکلات زیادی دارد! اگر کد جاوا اسکریپت نفوذی را به یک کاربر ارسال کنید احتمال دستگیر شدن شما پایین است؛ اما ارسال آن به هکرها و توسعه‌دهندگان وب این احتمال را بالا می‌برد. اینجاست که به یک فرمت دودویی نیاز خواهید داشت که هیچ انسانی قادر به خواندن آن نباشد! و تنها چیزی که باید حذف کنید، دکمه‌ی View Source است.

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