به نظر می‌رسد که نوشتن برنامه‌های ایمن‌تر، آرزوی هر دولوپری باشد اما این در حالی است که بسیاری از دولوپرها تصور می‌کنند چنین کاری بسیار دشوار می‌باشد. واقعیت این است که تنها با یاد گرفتن اصول اولیهٔ ایمن‌سازی، می‌توان جلوی درصد قابل‌توجهی از حملات امنیتی را گرفت که در این مقاله به چند اصل ساده پرداخته‌ایم که رعایت آن‌ها می‌تواند امنیت اپلیکیشن‌های تحت وب شما را به نحو چشمگیری ارتقاء بخشد.
همهٔ داده‌های ورودی کاربران را اعتبارسنجی کنید
یکی از بزرگترین اشتباهات امنیتی دولوپرها که بارها و بارها مرتکب می‌شوند، غفلت از اعتبارسنجی داده‌های ورودی کاربران است! حتی در سیستم‌های بک‌اند که تنها مورد استفادهٔ کاربران به اصطلاح Friendly قرار می‌گیرند نیز نادیده گرفتن اعتبارسنجی دادهٔ ورودی می‌تواند به طور بالقوه‌ای خطر حملات امنیتی را افزایش دهد (مثلاً ممکن است یک مجرم سایبری بتواند به نحوی به شبکهٔ شما وارد شده و سپس از داخل شبکه و با سوءاستفاده از این ضعف امنیتی بتواند به بخش‌های گسترده‌تری از سیستم نفو‌ذ کند.) بنابراین یک اصل ساده را همیشه به خاطر داشته باشید و آن هم اینکه هرگز به دادهٔ ورودی هیچ کاربری اعتماد نکنید. اگر با خود این‌طور تصور کنید که هر کاربری که از اپلیکیشن من استفاده می‌کند قصد حمله به آن را دارد، خودبه‌خود فکری به حال اعتبارسنجی جزء‌به‌جزء همهٔ داه‌های ورودی خواهید کرد و این در نهایت باعث ارتقاء امنیت برنامهٔ شما خواهد شد.
مثلاً اگر از کاربر خواسته‌اید که دادهٔ عددی وارد کند، پس حتماً بررسی کنید که دادهٔ ورودی کاربر فقط عدد باشد نَه چیز دیگر که اگر این کار را نکنید و هر داده‌ای را بپذیرید، خود را در معرض خطراتی مانند وارد کردن تگ‌های HTML به جای عدد قرار داده‌اید (در اکثر زبان‌های برنامه‌نویسی فانکشن‌هایی از پیش تعریف شده برای اعتبارسنجی داده‌های ورودی وجود دارد که به سادگی می‌توانید از این فانکشن‌ها استفاده کنید.)
جلوی حملات XSS را بگیرید
اعتبارسنجی داده‌های ورودی به تنهایی کافی نیست، بلکه داده‌های خروجی نیز قبل از اینکه در معرض دید کاربران قرار گیرند باید بررسی شوند (مخصوصاً در پروژه‌های بزرگی که در آن‌ها چندین دولوپر هم‌زمان کار می‌کنند، این موضوع اهمیت بیشتری پیدا می‌کند.) فرض کنید در یک چنین پروژه‌ای، در کدهای یکی از دولوپرها اعتبارسنجی دادهٔ ورودی کاربر نادیده گرفته شود؛ این موضوع بر آنچه که در دیتابیس ذخیره می‌شود تأثیر گذاشته و امنیت نرم‌افزار را به خطر خواهد انداخت چرا که دولوپر دیگری بدون توجه به سهل‌انگاری همکارش، داده‌ها را از دیتابیس گرفته و در معرض دید کاربران قرار می‌دهد که در این بین ممکن است کدهای مخربی که در دیتابیس ذخیره شده باشند نیز وجود داشته باشد (برای آشنایی بیشتر با حملات ایکس‌اس‌اس، به مقالهٔ آشنایی با مفهوم XSS و جلوگیری از آن در زبان برنامه نویسی PHP مراجعه نمایید.)
اجازه دهید برای روشن‌تر شدن این مسئله، یک مثال از دنیای واقعی بزنیم. فرض کنیم که وب اپلیکیشنی داریم که در آن از یوزر می‌خواهیم تا نام خود را وارد کند. دولوپری که این ماژول از وب اپلیکیشن را نوشته هم از قضا فراموش کرده است که دادهٔ ورودی را به اصطلاح Sanitize (اعتبارسنجی) کند. حال شما قصد دارید که نام کاربر را در صفحهٔ اختصاصی پروفایلش پرینت کنید اما غافل از اینکه پیش از این کاربری مشکوک به جای وارد کردن نام خود، یک تکه کد جاوااسکریپت وارد کرده است که این کد قابلیت این را دارا است تا دست به هر کاری بزند (از نصب بدافزار روی سیستم کاربر گرفته تا امکان دسترسی به بخش‌هایی از وب اپلیکیشن که وی مجاز به دسترسی نیست!)
هم‌زمان با کدنویسی اصول امنیتی را اِعمال کنید نَه پس از تکمیل کد
پرداختن به امنیت نرم‌افزاری که از قبل نوشته شده، هزینه‌های بیشتری برای دولوپر به بار خواهد آورد. از سوی دیگر، در این مرحله بسیاری از نقاط آسیب‌پذیر نرم‌افزار ممکن است از دید دولوپر مخفی بمانند و به راحتی قابل‌تشخیص نباشند. اگر می‌خواهید امنیت کدهای خود را بالاتر ببرید، باید در تمام مراحل توسعهٔ نرم‌افزار، از مرحلهٔ طراحی گرفته تا مرحلهٔ کدنویسی، موضوع امنیت را مد نظر داشته باشید.
در واقع، در حین کار دائماً به روش‌های احتمالی مورد حمله قرار گرفتن نرم‌افزار خود فکر کنید و راه‌حلی برای مقابله با آن‌ها بیابید و همواره به یاد داشته باشید که نوشتن یک خط کد ایمن همان‌قدر زمان می‌برد که نوشتن یک خط کد ناایمن اما اگر کد ناامنی بنویسید، بعدها باید زمان زیادی را صرف شناسایی و رفع نقاط آسیب‌پذیر آن کنید.
برنامه را به عنوان یک «کل منسجم» در نظر بگیرید
از آنجا که ممکن است دولوپرهای متعددی بر روی یک پروژه کار کنند، هر دولوپر علاوه بر رعایت امنیت کدهایی که خود نوشته است، باید امنیت کل اپلیکیشن را نیز مد نظر داشته باشد چرا که ناامن بودن بخش‌هایی که توسط یکی از دولوپرها نوشته شده ممکن است بر امنیت کدهای سایر دولوپرها و همچنین امنیت کل سیستم تأثیرگذار باشد.
پسوردها و اطلاعات حساس را رمزنگاری کنید
در مورد داده‌های حساس و مهم سعی نکنید الگوریتم رمزنگاری (Encryption) مخصوص خود را بنویسید، بلکه به جای آن از الگوریتم‌های نوشته شده و تست شده‌ای استفاده کنید که پیش از این امتحان خود را پس داده‌اند. به یاد داشته باشید که تاکنون هیچ‌کس از به کار بردن الگوریتم‌های رمزنگاری استاندارد و قوی ضرر نکرده است اما خیلی‌ها از تکیه نمودن به هوش و ذکاوت خود در این زمینه و سعی برای نوشتن الگوریتم‌های رمزنگاری خاص خود متضرر شده‌اند! اگر می‌خواهید چرخ را دوباره اختراع کنید، هیچ اشکالی ندارد، اما داده‌های مهم و حساس خود را موش آزمایشگاهی نکنید! نکتهٔ دیگری که در ارتباط با داده‌های حساس مثل پسورد، شماره کارت اعتباری و غیره وجود دارد اینکه این نوع داده‌ها را هرگز Encrypt نکنید بلکه آن‌ها را به اصطلاح Hash نمایید (برای آشنایی بیشتر با تفاوت‌های این دو، به مقالهٔ چه تفاوت‌هایی میان Encryption و Hashing وجود دارد؟ مراجعه نمایید.)
علاوه بر این، در نظر گرفتن یک Salt منحصربه‌فرد برای هر کاربر را هم فراموش نکنید. در توضیح اینکه منظور از Salt (به معنی نمک) چیست، بایستی گفت که فرض کنیم در وب اپلیکیشن خود جدولی داریم به نام users_table که در آن لیست کلیهٔ کاربران به علاوهٔ کلیهٔ اطلاعات ایشان مثل پسورد و ... ذخیره می‌شود. مسلماً نیاز به ستونی داریم همچون password که در آن پسورد کاربر را باید ذخیره کرد اما برای امنیت بیشتر، یک ستون هم می‌توانیم اضافه کنیم تحت‌عنوان salt و در آن به محض ایجاد یک کاربر جدید، یک عدد رَندُم (مثلاً ۴۵۶۷۶۳۹۸۷۶) ذخیره می‌سازیم. وقتی که یک کاربر جدید در وب اپلیکیشن ما ثبت‌نام می‌کند، برای خود یک پسورد دلخواه مثلاً iAMs@GOOD انتخاب می‌کند اما ما قبل از هَش کردن این استرینگ، Salt رَندُم را در کنارش قرار داده (iAMs@GOOD۴۵۶۷۶۳۹۸۷۶) سپس مجموع هر دو را هَش می‌کنیم. کاری که این Salt انجام می‌دهد این است که یک لایهٔ امنیتی دیگر به وب اپلیکیشن اضافه می‌کند و این باعث می‌شود که اگر هکری توانست یکسری پسورد را بیابد، در عین حال به خاطر عدم دسترسی به عدد رَندُم Salt، نخواهد توانست به اطلاعات بیشتری از کاربر دست یابد.
حال نوبت به نظرات شما می‌رسد. به غیر از راه‌کارهای فوق، چه استراتژی‌های دیگری می‌شناسید که می‌تواند ضریب امنیتی وب اپلیکیشن‌ها را ارتقاء بخشد؟ نظرات، دیدگاه‌ها و تجربیات خود در این حوزه را با دیگر کاربران سکان آکادمی به اشتراک بگذارید.