کاربرد و اهمیت ایجاد وب سایت های امن
ایجاد وب سایت های امن و فرم ها: آنچه شما باید بدانید
فرد یک مدیر اجرایی کسب و کار مشغول است. او یک توسعه دهنده ارزان را به صورت آنلاین استخدام کرد تا وبسایت پزشکی مطمئن خود را برای او تنظیم کند. توسعه دهنده یک گواهینامه SSL و صفحات راه اندازی که در آن بیماران می توانند قرار ملاقات ها را انجام دهند و پزشک می تواند درخواست و اعلامیه های بیمار را "به طور ایمن" دریافت کند. با این حال، توسعه دهنده آموزش واقعی در امنیت نداشت، هیچ کدام در HIPAA، و در نتیجه، PHI به صورت روشن ارسال شد، هیچ پیگیری های حسابرسی و یا سیاهههای مربوط وجود دارد، امنیت SSL اجرا نشد، و ممکن است دیگر مسائل جدی زحمت سایت بدترین قسمت هیچ کس نمی دانست.
خوشبختانه، فرد از وضعیت پیش از نقض جدی امنیتی (که او می دانست) رخ داده است؛ با این حال، او مجبور شد که سایت را از ابتدا، بیش از دو برابر زمان و هزینه های خود را دو برابر کند.
ایجاد صفحات وب و فرم های امن
ایجاد یک وب سایت که دارای اجزای امن است نیازمند بیش از یکپارچه کردن برخی صفحات وب و اضافه کردن گواهی SSL است. همه این گواهینامه ها واقعا باعث ایجاد یک پوشش نازکی از امنیت می شود - یکی از آن ها که برای امنیت هر گونه داده های حساس ضروری نیست، از وظایف مهم امنیتی برخوردار نیست. در واقع، تلاش های ساده و بی تکلف در امنیت، در نهایت می تواند داده ها را با ایجاد یک هدف اشتباه برای بی عدالتی، امن تر و خطرناک تر سازد.
بنابراین، فراتر از پرداختن به دلارهای بزرگ برای استخدام یک توسعه دهنده با تخصص امنیت طراحی وب سایت امن است و آنچه شما می توانید برای حل و فصل آنها انجام دهید. به حداقل، خواندن این مقاله به شما کمک خواهد کرد هوشمندانه در مورد امنیت وب سایت خود با توسعه دهندگان که در نهایت استخدام می کنید صحبت کنید.
چه چیزی در امنیت وب سایت دخیل است؟
امنیت وب سایت یک موضوع عمیق و پیچیده است. ما فقط برخی از نکات بالا را می بینیم. تمرکز این مقاله این است که به مسائل امنیتی مرتبط با یک فرم وب سایت که برای ایمن جمع آوری اطلاعات از بازدید کنندگان شما طراحی شده است. چه چیزی می تواند ساده باشد، درست است؟
خوب، نه کاملا. در اینجا برخی از مسائل مورد نیاز باید مورد توجه قرار گیرد:
SSL - آیا فرم ایمن شده است به طوری که داده ها از طرف کاربر نهایی به طور ایمن منتقل می شوند و آیا سایت شما باعث اعتماد شما می شود؟ آیا برای خود صفحه خود را با SSL محافظت کرده اید تا از محرمانه بودن مطالب آن جلوگیری شود؟ (در اینجا از SSL به عنوان اصطلاح عمومی استفاده شده برای TLS استفاده میکنیم: SSL vs TLS ... تفاوت چیست؟)
محتوای صفحه وب - آیا محتوای HTML به کاربر نهایی محافظت شده از مسائل پیچیده اسکریپت سایت (XSS) ارسال می شود یا آیا از اشیاء بارگیری به صورت نا امن و یا از طرف شخص ثالث جلوگیری می شود؟
امنیت اسکریپت - آیا اسکریپت ها یا برنامه هایی هستند که داده های ارسال شده را با توجه به امنیت پردازش می کنند؟ آیا آنها آسیب پذیری دارند؟
زیرساخت - آیا ارائه دهنده ی میزبانی وب شما از اعتماد به نفس و شناخته شده برای امنیت خوب استفاده می کند؟ آیا شما در یک سرور به اشتراک گذاشته می شوید زمانی که شما باید در یک اختصاص داده شده است؟
داده ها - پس از ارسال اطلاعات با داده ها چه کار می کنید؟ آیا داده ها امن شده اند؟
پیگیری - آیا رویدادهایی نظیر دسترسی به داده ها و ارسال داده ها را پیگیری می کنید؟
آرشیو و پشتیبان گیری - آیا وجود دارد فرآیندهای در محل برای ایجاد پشتیبان گیری و بایگانی دائمی از اطلاعات مهم؟
SSL - امنیت شبکه شروع می شود در اینجا
یک گواهی SSL برای وب سایت ایمن ضروری است. گواهی SSL اجازه می دهد:
داده ها ارسال شده به و از سرور وب و کاربران شما برای رمزگذاری
بنابراین نمی توان بر آن غافل شد
بنابراین نمی توان با آن دستکاری کرد و تغییر کرد.
کاربران خود را به اعتماد به این که آنها به وب سایت شما به طور امن اتصال و می دانیم که سایت شما امن است
یک گواهینامه SSL در یک وب سرور به درستی پیکربندی، رمزگذاری داده های وب سایت شما را به عنوان و از کاربران نهایی شما منتقل می کند.
برای دریافت یک گواهینامه SSL، می توانید به صورت مستقیم از طرف شخص ثالث مانند Comodo سفارش دهید یا با ارائهدهنده سرویس میزبانی وب خود تماس بگیرید و ببینید آیا می توانید یکی را برای شما به دست آورید. در هر صورت، میزبان وب شما باید گواهی را روی سرور که وبسایت شما میزبانی شده است نصب کند و سپس باید به سایت خود تغییراتی بدهید تا بتوانید از کانال امن که اضافه کرده اید استفاده کامل کنید.
SSL و رمزگذاری
از مهمترین دلایلی که مردم از SSL برای امنیت صفحات وب سایت خود استفاده می کنند این است که رمزگذاری داده ها ارسال شده به و از وب سایت و کاربر نهایی را ارائه دهند. هنگامی که کاربر نهایی یک صفحه از شما را که توسط SSL محافظت می کند، مرورگر وب خود را با یک وب سایت با یک کانال امن ارتباط برقرار می کند و تمام داده های ارسال شده بر روی این کانال رمزگذاری شده ارسال می شود. این به جلوگیری از استراق سمع و حمله "مرد در میان" به داده ها کمک می کند (بیشتر در این موارد زیر).
بدون رمزنگاری SSL، اطلاعات کم و یا هیچ گونه حفاظت وجود ندارد. ما اکنون بررسی خواهیم کرد که مطمئن شوید که چیزهایتان را به درستی تنظیم کرده اید تا استفاده حداکثر از SSL و جلوگیری از آن را نادیده بگیرید.
همچنین ببینید: چگونه لایه سوکت امن (SSL یا TLS) کار می کند؟
SSL و اعتماد
جنبه نادیده گرفته شده و سوء تفاهمی SSL ایجاد است
زنگ. به این معناست که کاربران نهایی شما را قادر می سازد تا به وب سایت واقعی خود اعتماد کنند. چه چیز دیگری می تواند آنها را به اتصال، شما ممکن است بپرسید؟
کسی که دسترسی به شبکه بین کاربر نهایی و سایت شما داشته باشد می تواند سعی کند همه ترافیک وب را بخواند و یا صفحات خود را تغییر دهد (به عنوان مثال تغییر فرم ها برای ارسال داده ها به آنها به جای شما). این یک مرد در وسط است که استراق سمع می کند، و بی اهمیت است که بدون امنیت SSL انجام شود. حتی با امنیت SSL، اگر مردی در وسط می تواند کاربر نهایی را با یک گواهی SSL برای نام دامنه خود که اعتماد آنها را دارد و خوب به نظر برسد (به عنوان مثال کارت شناسایی جعلی)، آسان است.
کاربران می توانند از یک وب سایت دیگر بازدید کنند که وانمود می کند شما (به عنوان مثال به نظر می رسد درست مثل شما). این وب سایت "فیشینگ" می تواند در تلاش برای جمع آوری اطلاعات از کاربران شما برای اهداف خود باشد. به استثنای اینکه کاربران شما می توانند شناسایی کنند که این سایت غیر قانونی است، آنها به راحتی می توانند به آشکار سازی نام های کاربری، رمزهای عبور و اطلاعات شخصی متهم شوند. چگونه می توانستند در یک وب سایت فیشینگ مانند این کار را انجام دهند؟ این می تواند به عنوان مثال، کلیک کردن بر روی یک لینک وب سایت به آنها ایمیل در ایمیل های مخرب و یا آنها را به نسخه ای اشتباه از آدرس وب سایت شما. هیچ سایت ایمنی از چنین حملاتی ندارد، اما شما می توانید آنها را کاهش دهید.
بنابراین، گواهی SSL شما چگونه می تواند احتمال استعفای، مردی در میان و فیشینگ را کاهش دهد؟
گواهینامه های SSL توسط یک شخص ثالث، به اصطلاح "گواهینامه"، امضا می شود. این میتواند باشد:
شما، اگر گواهی های خود را امضا کنید
صدور احکام شخص ثالث:
یک گواهی ارزان یا رایگان که تنها دامنه شما را تأیید میکند
گران تر گواهی "تمدید اعتبار" که همچنین سازمان شما را تأیید می کند
اگر گواهینامه های خود را امضا کنید، وب سایت شما هشدارهای اعتماد ایجاد می کند که هر کسی می آید از آن بازدید کند. اگر بازدیدکنندگان به طور دائمی به گواهی خود امضاء خود اعتماد داشته باشند، می توان از آنها برای برداشت هر بازدید کننده استفاده کرد. با این حال، برای وبسایت عمومی هرگز توصیه نمی شود زیرا گواهی های امضا شده خود هیچ اعتقادی ذاتی را که مشروع هستند (هر کسی می تواند یک سایت را به عنوان یک سایت تولید کند) ارائه می دهد، آنها به دنبال آماتور هستند و آنها را به کاربر نهایت آزار می دهد. گواهی های خود امضا باید فقط در محیط های داخلی یا آزمایش مورد استفاده قرار گیرد.
هنگام سفارش یک گواهی از یک شخص ثالث مورد اعتماد (مثلا Comodo یا Verisign)، انواع مختلفی از گواهینامه هایی وجود دارد که می توانید آنها را سفارش دهید. آنهایی که سریع و ارزان هستند صرفا یک ایمیل برای تماس با دامنه شما ارسال می کنند و اگر شما می توانید روی لینک کلیک کنید - گواهی دریافت می کنید. این گواهی "دامنه تایید شده" خوب است و امنیت زیادی را ارائه می دهد؛ با این حال، به عنوان یک انسان در فرآیند اعتبارسنجی دخالت نمی کند، ممکن است برای یک مهاجم راحت تر از این گواهی ها غیرقانونی باشد.
شما همچنین می توانید مدارک اعتبار سنجی تمدید شده را سفارش دهید. آنها بیشتر هزینه می کنند؛ زیرا افراد واقعی در واقع سازمان شما و مالکیت خود را در دامنه تأیید می کنند. آنها تماس تلفنی برقرار می کنند و اطمینان می دهند که همه چیز درست به نظر می رسد. اگر یکی از این گواهینامه ها دارید، نوار آدرس مرورگرتان سبب می شود که بازدیدکنندگان به آنجا برسند ... برای نشان دادن این که "سلام، این یک سایت واقعا قابل اعتماد است!" اگر می خواهید اعتماد به نفس بیشتری داشته باشید و برای پایان دادن به آن بسیار آسان باشد کاربران برای شناسایی سایت خود به عنوان مشروع و به راحتی می توانید بگویید اگر کسی در تلاش است تا آنها را با یک گواهینامه جعلی فریب دهد، شما می خواهید از یک گواهی اعتبار سنجی تمدید استفاده کنید. این هزینه ها بیشتر است، اما به لحاظ امنیت و اعتماد که آنها ارائه می دهند، ارزش آن را دارند. مراجعه کنید: گواهی SSL Validation Extended (EV) و چرا گواهی OVSL را انتخاب می کنید؟
اگر گواهینامه EV و OV خارج از بودجه شما باشد، باید با یک گواهینامه SSL از طرف شخص ثالث مورد اعتماد استفاده کنید.
تأیید فرم وب خود را با SSL
هنگامی که وب سایت شما دارای یک گواهی SSL است و توسط میزبان وب خود نصب شده است، صفحات وب خود را می توانید با آدرس هایی که به جای "http: //" شروع می شوند با https: // شروع می شود. "S" در "https" به معنای "امن" است. توجه داشته باشید:
هنگامی که شما به یک صفحه وب با استفاده از یک آدرس ایمن مانند "https://yourdomain.com" متصل می شوید، یک مرورگر وب نماد "قفل" برای نشان دادن اینکه اتصال امن است نشان می دهد.
صفحات وب که در ".shtml" پایان می یابند لزوما امن نیستند. "S" به معنای "سرور" (به عنوان مثال صفحه سرور پردازش شده) و "امن" نیست. بنابراین، برای مثال، "http://yourdomain.com/index.shtml" یک صفحه امن نیست، اما "https://yourdomain.com/index.html" یک صفحه امن است.
در بسیاری از پیکربندیهای وب سرور به طور پیش فرض که دارای SSL فعال هستند، می توانید به یک صفحه به صورت امن و ناامن دسترسی پیدا کنید. ایده هر دو "http://yourdomain.com/form.html" و "https://yourdomain.com/form.html" کار می کنند و فرم را نشان می دهند - تنها تفاوت استفاده از SSL یا نه.
بنابراین، اجازه می دهد می گویند که شما یک فرم وب واقع در "http://yourdomain.com/form.html" واقع شده است. شما گواهی SSL دریافت کرده اید و میزبان وب شما آن را نصب کرده است. بعد
تو می خواهی که:
اطمینان حاصل کنید که مردم ایمن به صفحه فرم شما وصل شوند
اطمینان حاصل کنید که هیچ کس نمی تواند به صفحه فرم شما متصل شود
این دو هدف ممکن است یکسان باشند، اما اینها نیستند.
اطمینان حاصل کنید مردم با امنیت به صفحه فرم شما ارتباط برقرار می کنند
از آنجا که صفحات وب سایت منظم شما احتمالا ناامن هستند، باید مطمئن شوید که پیوندهای به صفحه فرم ایمن شما، لینکهای مطلق با پیشوند «https: //» شروع می شوند. این اطمینان حاصل خواهد کرد که هر کسی که روی این پیوندها کلیک کند به صفحه فرم شما بر روی یک اتصال امن منتقل خواهد شد.
بهترین راه این است که از HSTS (HTTP Strict Security Transport) استفاده کنید که به مرورگرها می گوید که همیشه باید از نسخه ایمن وب سایت شما استفاده کنند. اگر شما انتخاب کنید که هر دو نسخه (وب سایت) ایمن (http) و ایمن (https) شما در همان زمان اجرا می شوند (توصیه نمی شود)، پس باید با پیوندهای خود مراقب باشید تا صفحات حساس شما امن شوند:
لینک های اشتباه: لینک نسبی توصیه نمی شود، زیرا اگر کاربر در یک صفحه ناامن سایت شما باشد، لینک های نسبی همیشه آنها را به نسخه های ناخواسته صفحه مقصد منتقل می کند. بنابراین لینک های نسبی مانند موارد زیر باید اجتناب شود:
<A href="/form.html "> فرم من را پر کنید </a>
<a href="form.html"> فرم من را پر کنید </a>
لینک های صحیح: لینک مطلق یک اتصال امن را با مشخص کردن اینکه SSL باید از طریق پیشوند لینک "https: //" استفاده شود، تضمین می کند. مثلا:
<a href="https://yourdomain.com/form.html"> فرم من را پر کنید! </a>
اطمینان حاصل کنید که لینکهای ALL به تمام صفحههای ایمن سایت شما با استفاده از این قالب مطمئن با پیشوند https: // استفاده میکنند.
نکته جانبی: امروزه توصیه می شود از SSL برای ALL صفحات وب سایت خود استفاده کنید، نه فقط "مهم" ها. این برای اعتماد کاربر، امنیت و حریم خصوصی مفید است. این نیز برای بهینه سازی موتورهای جستجو مفید است (همانطور که گوگل به شما برای تأمین امنیت سایت شما پاداش می دهد). اگر سایت خود را راه اندازی کرده اید، بنابراین تمام صفحات امن هستند، همیشه، سپس لینک های نسبی یک بار دیگر امن هستند.
اطمینان حاصل کنید که هیچ کس نمیتواند به طور مستقیم به فرم فرم شما مرتبط شود
بنابراین، در حال حاضر همه لینک ها در سایت شما کاربران خود را به نسخه امن مناسب فرم خود را. با این حال، همانگونه که قبلا ذکر شد، اکثر وبسایتها نسخه ناامن فرم را ترک می کنند و اگر کاربران به طور مستقیم به آدرس ناامن (یا اگر بعضی از لینک ها را در به روز رسانی های شما از دست رفته)، کاربران بتوانند از آنها استفاده کنند. به عنوان یک گام بعدی، باید اطمینان حاصل کنید که دسترسی به صفحه فرم از طریق یک اتصال ناامن امکان پذیر نیست. این قفل کردن یا اعمال استفاده از SSL برای این صفحه است.
راه های مختلفی وجود دارد که می توان این کار را انجام داد. برخی از این موارد عبارتند از:
فضای جداگانه برای صفحات SSL: اگر میزبان وب شما این ویژگی داشته باشد، می توانید وب سایت خود را پیکربندی کنید تا صفحات وب برای اتصالات امن (SSL) در یک پوشه متفاوت از صفحات ناامن ذخیره شوند. اگر این ویژگی را فعال کنید، صفحه فرم و هر صفحه دیگر امن را در پوشه ایمن قرار دهید و مطمئن شوید که هیچ نسخه ای از این صفحات در پوشه ناامن وجود ندارد. بنابراین، هر گونه درخواست ناامن برای این صفحات نتیجه خطای صفحه را پیدا نمی کند. پس از آن، می توانید برخی از قوانین تغییر مسیر سرور را اجرا کنید، در صورتی که کسی از صفحه ناامن درخواست می کند، آنها به صورت خودکار به نسخه امن هدایت می شوند (این کار با استفاده از فایل های .htaccess و "Direction") انجام می شود. اگر این کار را انجام دادید، درخواستهای ایمن و ناامن برای این صفحه، کاربر را به نسخه ایمن بدون خطا، هشدار یا مشکل برای کاربر نهایی می برد.
صفحات اسکریپت: اگر صفحه فرم شما توسط یک اسکریپت سمت سرور تولید شده باشد (یعنی PHP، Perl، Python یا JAVA)، سپس اسکریپت خودتان می تواند نگاه کند و ببیند آیا درخواست امن است یا خیر (به عنوان مثال با نگاه کردن به محیط سرور متغیرها) برای درخواست های امن، می تواند فرم را به طور معمول ارائه دهد. برای درخواست های ناخواسته، می تواند کاربر را یک خطا یا یکپارچه را به مکان مناسب امن هدایت کند.
اطمینان از تمام صفحات: (توصیه شده) شما می توانید سایت خود را پیکربندی کنید تا تمام درخواست ها برای صفحات ناامن به طور خودکار به صفحه امن مربوطه هدایت شوند. به این ترتیب، تمام صفحه ها امن خواهند بود و هر گونه درخواست تصادفی / نادرست برای صفحات ناامن، مردم را در جای مناسب قرار می دهند. اگر شما این را به طور فراگیر برای سایت خود تنظیم کرده اید، امنیت بسیار بهبود یافته است.
اگر فرم من بی درنگ به اسناد تصدیق فرم فرم ارسال شود، پس چرا فرم خود را به امنیت نیاز دارد؟
معمولا این سوال زمانی مطرح می شود که پردازش فرم توسط یک شخص ثالث مدیریت می شود - آیا خود فرم با SSL مورد نیاز است؟
به عنوان مثال. آیا صاحب وب سایت باید زمان و هزینه هزینه واقعی دریافت گواهینامه SSL برای وب سایت خود را تحت پوشش قرار دهد؟
پاسخ بر اساس حقایق زیر است:
اطلاعات ارسال شده از طرف کاربران نهایی به سرور امن و رمزگذاری شده در طول انتقال خواهد بود. این برای برخی از برنامه های کاربردی مانند HIPAA بسیار مهم است.
فرم خود را به کاربر نهایی رمزگذاری فرستاده می شود. اگر چیزی در قالب خود حساس نیست، این خطرناک است. یک مرد-in-the-middle می تواند به صورت صریح این فرم ناامن را تغییر دهد به طوری که به سرور مهاجم (به طور ایمن)، ضبط اطلاعات حساس کاربران خود را ارائه کند.
کاربران نهایی که غیر فنی هستند هیچ راهی برای دانستن اینکه آیا داده های آنها به صورت ایمن ارائه می شوند تا زمانی که واقعا آنها را امتحان کنند، وجود ندارد. بسیاری از کاربران نهایی بخاطر این دلیل نمی خواهند داده های خود را به شکل ناامن در سایت شما ارسال کنند.
کاربران نهایی هیچ راهی برای دانستن اینکه آیا آنها سایت شما را مشاهده می کنند، یا یک سایت فیشینگ، یا در صورت استراق سمع و اصلاح وجود دارد. بسیاری از کاربران به اتصال اعتماد ندارند و نمی خواهند داده های خود را از طریق سایت شما ارسال کنند.
اگر صفحه فرم شما ناامن باشد، برای هر حزب مخرب بسیار آسان است که یک حمله مردانه در میان تماس ها را انجام دهد تا فرم را در حمل و نقل تغییر دهد تا بتواند آنچه را که جمع آوری شده است و در آن داده ها ارسال شود، تغییر دهد و برای راه اندازی سایت های فیشینگ برای کاربران نهایی شما غیرممکن است که این کار را انجام دهد.
اگر وب سایت خود را به صورت SSL امن نکنید، آن را بسیار آسیب پذیر کنید و به هیچ وجه برای کاربران نهایی خود به سایت خود اعتماد نکنید. اگر هیچ چیز غیر قابل پیش بینی وجود نداشته باشد، شما باید امنیت انتقال را به آن تکیه کنید؛ با این حال، حداقل سطح امنیت برای وب سایت های تولید و یا هر جایی که نیاز به انطباق است توصیه نمی شود.
امنیت وب بیش از SSL است
سایر نکات امنیتی امنیت وب
استفاده مناسب و قفل کردن اتصال SSL برای رمزگذاری و اعتماد فقط بخشی از امنیت وب است. جنبه های دیگری نیز وجود دارد که باید به منظور حفاظت از کاربران خود، درخواست خود و شهرت شرکتتان مورد توجه قرار گیرید. این شامل (اما نه محدود به):
Cross Script Scripting (XSS). اگر محتوایی پویای را در صفحات وب خود (یعنی چیزهایی که توسط کاربران دیگر یا محتوای ارائه شده از طریق فیلدهای فرم ارسال شده) را شامل کنید و محتوای آن از چیزهایی مانند جاوا اسکریپت و HTML پاک نشده باشد، ممکن است افراد بتوانند محتوای دلخواه خود را بر روی خود ظاهر کنند وب سایت، گرفتن اطلاعات از کاربران شما و بدتر شدن. تمام داده های نمایش داده شده باید از محتوای نامطلوب (برچسب های اسکریپت، کاراکترهای خاص، HTML و موارد دیگر) تمیز شود. این یکی از بزرگترین مسائل امنیتی با صفحات وب پویا در اینترنت است.
برنامه نویسی امن سرور: اسکریپت ها و برنامه هایی که داده ها را از فرم شما پذیرفته و پردازش می کنند باید با توجه به امنیت ایجاد شوند. آنها باید تمام داده های ارائه شده را در صورت لزوم تأیید کنند، و هیچ فرضیه ای درباره قالب و محتوای آن ندارند. آنها نباید برای حملات از قبیل "تزریق SQL" و استفاده از محتوای ارسال شده به عنوان نام فایل یا URL واقعی برای بارگیری محتوای از راه دور ارائه دهد. آنها باید هر گونه اشتباه و عجیب و غریب را برای تجزیه و تحلیل بعدی وارد کنند. آنها باید در صورت امکان مکانی برای جلوگیری از اقدامات نامطلوب یا کاربران از استفاده از اسکریپت ها ارائه دهند.
اعتبار سنجی: تایید تمام داده های ورودی چیزی است که بخشی از دو مورد فوق است. با این حال، این بسیار ضروری است که ما آنرا تکرار خواهیم کرد و برخی از نکات اساسی را نیز خواهیم داشت:
اگر محتویات ارسال شده را تأیید کنید، همیشه اعتبار خود را در قسمت سرور انجام دهید. حتی اگر از جاوا اسکریپت برای تایید داده ها در سمت سرویس گیرنده استفاده می کنید، همیشه باید در سمت سرور مجددا اعتبار دهید. چرا؟ از آنجا که مردم می توانند جاوااسکریپت خود را بیرون بیاورند و محتوای دلخواه خود را مستقیما به اسکریپت خود ارسال کنند، اسکریپت ها باید بتوانند آن را مدیریت کنند.
همیشه اطلاعات داده شده را از بین می برد معنی آن چیست؟ این بدان معنی است که هرگز به داده های ارسالی اعتماد نکنید و به دردسر بیفتید تا اطمینان حاصل شود که داده های ارائه شده با همان انتظارات شما مطابقت دارند. به عنوان مثال، اگر شما یک لیست انتخاب کنید که اسکریپت شما یک عدد را به عنوان مقدار می فرستد، فرض نکنید که شما در واقع یک عدد را دریافت می کنید! در عوض، بررسی کنید که واقعا یک مقدار عددی است یا هرکدام را به یک عدد تبدیل کنید.
حذف محتوای غیر مجاز از متن ارائه شده توسط کاربران. ایده کاراکترهای خاص، کدهای جاسازی شده و موارد دیگر که "باید وجود نداشته باشد" باید بررسی شود و حذف شود یا مسدود شود.
اطمینان حاصل کنید که داده های ارسال شده "بیش از حد بزرگ" برای استفاده نیست.
هر چیزی را قبول نکنید - برنامه دفاع کنید.
حفظ حالت با فیلد پنهان Fields یا کوکی ها: اگر برنامه شما چیزهایی را از یک صفحه به صفحه دیگر با ذخیره اطلاعات در فیلدهای فرم پنهان، برنامه خود نیز باید اطمینان حاصل کند که محتوای این فیلدها با آن دستکاری نباشند! یک راه خوب برای انجام این کار این است که یک هش از تمام داده ها، همراه با یک مقدار مخفی داشته باشید و همچنین این هش را در فرم داده نیز قرار دهید. سپس، هنگامی که فرم ارسال شده است، می توانید هش را مجددا پردازش کنید و آن را با آنچه که از فرم منتقل شده است مقایسه کنید. اگر آنها مطابقت داشته باشند، شما خوب هستید؛ اگر این کار را نکنند، داده ها با آن دستکاری می شوند. هیچ کس نمی تواند بدون دانستن مقدار مخفی خود و یا بدون شکستن الگوریتم هش کردن خود، این طرح را شکست دهد. این روش همچنین می تواند برای تأیید اطلاعات ذخیره شده در کوکی ها مورد استفاده قرار گیرد. شما می توانید یک مرحله بیشتر بروید و از تمبرهای زمان استفاده کنید تا از حملات بازپخش جلوگیری کنید.
برنامه های کاربردی شخص ثالث: اگر شما برنامه های خود را از طرف شخص ثالث در وب سایت خود نصب می کنید، پس باید مراقب باشید که وجود داشته باشد
هر گونه مسائل امنیتی شناخته شده با این برنامه ها را نداشته باشید و باید مطمئن شوید که این برنامه ها به محض انتشار نسخه های جدید به روز می شوند. اگر اجازه دهید وب سایت شما با یک نسخه قدیمیتر و آسیب پذیر از یک برنامه بر روی آن نومید شود، به عنوان هکرها برای هکرها به طور دائم برای چنین وب سایت ها جستجو می کند. احتمالا سایت شما در این موارد هک شده است، احتمالا باعث از بین رفتن کسب و کار، غیرفعال کردن وب سایت شما و خرابکاری شهرت وب سایت شما خواهد شد. با استفاده از یک برنامه شخص ثالث سریع و آسان است، اما شما باید مطمئن شوید که یک انتخاب خوب را انتخاب کنید، و بار نگهداری آن را به شما به روز رسانی می کند. استثنا با استفاده از یک برنامه شخص ثالث است که توسط شخص ثالث میزبانی شده است. در این موارد، شخص ثالث تضمین می کند که برنامه همیشه با هر چیز مورد نیاز برای رسیدگی به هر گونه مسائل امنیتی که ممکن است بوجود می آید به روز می شود - بار بر آنها و نه شما است. اگر فروشنده یک فروشنده خوب و قابل احترام را انتخاب کنید، پس هیچ مشکلی ندارید، به عنوان مثال ببینید: وردپرس برای HIPAA و ePHI؟
همه اینها و بیشتر، برای توسعه یک برنامه وب ایمن حیاتی هستند.
اطمینان از این اطلاعات پس از آن وارد می شود
اطمینان از اینکه داده های کاربران شما به طور ایمن به سرور وب شما منتقل می شود مطمئنا حائز اهمیت است، زیرا حصول اطمینان از اینکه برنامه شما امن است و هک نمی شود. با این حال، پس از اینکه برنامه شما آن را دریافت کرد، چه اتفاقی می افتد؟ آیا هنوز نیاز به حفاظت از آن دارید؟ آیا باید رمزگذاری شود؟ چگونه داده ها را دریافت می کنید یا دریافت می کنید؟ بسیاری از مردم فراموش می کنند که گرفتن داده ها از سرور وب به آنها ایمن ممکن است نیاز به همان آماده سازی برای دریافت آن از کاربران خود را در وهله اول!
در بخش های زیر، ما به سه روش مختلف ذخیره و بازیابی اطلاعات کاربران خود نگاه می کنیم و ببینید چه چیزی در هر مورد مورد نیاز است تا امنیت داده ها را از کاربران خود به چشم شما حفظ کند و سپس در دیسک و پشتیبان گیری ذخیره شود .
1. ارسال اطلاعات به شما
از مهم ترین اقداماتی که اسکریپت های پردازش داده انجام می دهند، ایمیل های داده شده ارسال شده به آدرس ایمیل صاحب وب سایت است. صاحب وب سایت می داند زمانی که ارسال های جدید را فقط با چک کردن ایمیل خود انجام می دهد و می تواند بلافاصله در آن اطلاعات دسترسی پیدا کند. همانطور که اکثر مردم وب سایت ها را اجرا می کنند اغلب ایمیل های خود را چک می کنند، این به خوبی با عملیات تجاری خود هماهنگ است.
با این حال، روش های استاندارد ارسال ایمیل به طور کامل ناامن است. برای درک دلیل، نگاه کنید به مورد برای امنیت ایمیل. بنابراین، برای استفاده از ایمیل هنوز می توانید انجام دهید، اما اطمینان حاصل کنید که داده ها تنها توسط بینندگان مورد نظر امن و قابل مشاهده هستند؟
اسکریپت وب سایت خود را رمزگذاری کنید.
ارسال این داده های رمز شده (یا یک لینک برای دانلود داده های رمز شده) به بینندگان مورد نظر از طریق ایمیل معمولی.
همانطور که داده های فرم در پیام ایمیل رمزگذاری می شوند، اغلب ناامنی های ذاتی در ایمیل حذف می شوند.
برای جزئیات بیشتر در مورد ایمنی فرم های ایمیل شما با این روش، به Recipe: Completely Secure مجموعه ای از داده های وب فرم با استفاده از SSL و PGP یا S / MIME مراجعه کنید. شما همچنین می توانید از خدمات شخص ثالث ایمن استفاده کنید تا داده های فرم شما به شما ایمن ایمیل بدون نیاز به برنامه هر چیزی خودتان.
2. صرفه جویی در داده ها در یک پایگاه داده
بسیاری از صاحبان وب سایت ها مایلند داده های فرم ارسال شده در یک پایگاه داده را ذخیره کنند (حتی اگر به آنها ایمیل فرستاده شود). چرا؟
داده ها به صورت آنلاین ذخیره می شوند و به طور بالقوه از هر کجا قابل دسترسی هستند
اگر نسخه های ایمیل داده ها از بین رفته باشند، نسخه های موجود در پایگاه داده هنوز وجود دارد
اگر یک رابط کاربر مناسب وجود داشته باشد، داده ها در پایگاه داده می توانند از طریق یک مرورگر وب قابل دسترسی باشند
احتمالا این اطلاعات برای شما پشتیبانی می شود
خوب، پس اگر ذخیره سازی در پایگاه داده آنلاین برای شما باشد، پس شما باید:
به صورت اختیاری - از نوع رمزنگاری مانند SSL یا PGP استفاده کنید تا اطمینان حاصل شود که داده ها در پایگاه داده به صورت رمزگذاری شده ذخیره می شوند. چرا؟ محتویات جداول پایگاه داده به طور کلی رمزگذاری نشده و یا امن نیستند. ذخیره سازی داده های رمزنگاری باعث می شود که داده ها به هر کسی دیگری دسترسی داشته باشند به پایگاه داده و یا پشتیبان گیری آن. نگاه کنید به: رمزگذاری و حسابرسی پایگاه های MySQL برای HIPAA.
یک رابط کاربر فراهم می کند که به شما امکان دسترسی به داده های پایگاه داده را می دهد. این رابط کاربری باید امن باشد، کنترل دسترسی قوی داشته باشد و باید وسیله ای برای رمزگشایی داده های رمز شده برای شما فراهم کند.
اگر واقعا علاقه مند به امنیت هستید، گزینه پایگاه داده در واقع نیاز به کار و هزینه بسیار زیادی برای ایجاد یک راه حل امن و قابل استفاده است. به همین دلیل، اکثر سازمان های کوچک به استفاده از ذخیره سازی پایگاه داده امن برای داده های مهم فرم پایبند نیستند.
3. صرفه جویی در داده ها در فایل ها
گزینه ذخیره سازی فایل، جایگزینی سریع و کثیف برای ذخیره سازی پایگاه داده است. اساسا، برنامه شما:
یک فایل حاوی تمام اطلاعات فرم را ایجاد کنید
رمزگذاری این فایل با استفاده از PGP یا SSL
این فایل رمزگذاری شده را در یک دایرکتوری در وب سرور ذخیره کنید که از وب سایت قابل دسترسی نیست یا آن را در یک سرویس به اشتراک گذاری فایل آنلاین ذخیره کنید.
سپس، صاحبان وب سایت می توانند با استفاده از FTP Secure وارد وب سرور شوند و این فایل ها را دانلود کنید
مورد نیاز است هنگامی که داده ها باید دسترسی داشته باشند، می توانند بصورت محلی رمزگشایی شوند. یا، در مورد فایل هایی که در اشتراک گذاری فایل آنلاین ذخیره می شوند، دیگر مکانیزم های ساده تر برای دسترسی به داده ها در دسترس هستند.
این راه حل امن است و پشتیبان خوبی برای ایمن ایمیل ارسال شده است.
چقدر امن وب سایت شماست؟
انتخاب ارائه دهنده ی میزبانی وب و محیط زیست برای امنیت برنامه وب سایت بسیار مهم است.
ارائه دهنده ی میزبانی وب که در امنیت تخصص ندارد، به احتمال زیاد زیرساخت های ویژه ی امنیتی نخواهد داشت و نرم افزاری که استفاده می کند، بیشتر احتمال آسیب پذیری های ناخواسته را دارد. این باعث می شود که وب سایت شما به طور قابل توجهی کمتر امن باشد.
اگر ارائه دهنده ی میزبانی وب شما خط مشی های امنیتی و محرمانه ای نداشته باشد یا به طور کلی به دلیل اطمینان از داده های شما اعتماد نداشته باشد، ممکن است مشکلی داشته باشید. مدیران سیستم و کارمندان پشتیبانی فنی در ارائه دهنده می توانند به درخواست وب سایت شما و داده های خام دسترسی داشته باشند. اگر داده ها رمزگذاری نشوند، می توانند آن را بخوانند و کپی کنند. آنها می توانند برنامه را برای ضبط و ذخیره اطلاعات تغییر دهند. آیا شما حس خوبی دارید که این اتفاق نخواهد افتاد؟
آیا شما در یک سرور وب اختصاصی یا مشترک هستید؟ اگر شما در یک سرور وب مشترک هستید و یک وب سایت دیگر در آن سرور یا خود سرور به خطر می افتد، همچنین وب سایت و داده های شما نیز بسته می شود (بسته به ماهیت مسئله). اگر بتوانید آن را بپردازید، سرور اختصاصی و سرورهای اختصاصی مجازی سایت خود را با سطح بسیار بالایی از امنیت ارائه می دهد تا یک حساب میزبانی مشترک ارائه دهد.
سایر راهنمایی های فنی فنی
بسیاری از ملاحظات دیگر در توسعه و نگهداری یک وب سایت ایمن تولید وجود دارد. برای پوشش دادن یا حتی فهرست همه آنها در اینجا غیرممکن است. با این حال، در اینجا چند نکته جالب و مفید هستند.
استفاده از غذاهای امن
اگر سایت ایمن شما کوکی ها را برای هر چیزی استفاده کند، مطمئن شوید که پرچم "امن" کوکی (و پرچم "httpOnly") را تنظیم کنید. این اطمینان حاصل خواهد کرد که این کوکی ها هر روز به صورت نا امن در اینترنت ارسال می شوند زمانی که بازدید کننده وارد هر صفحه ناامن وب سایت شما می شود (به هیچ وجه به صفحات ناامن ارسال نمی شود) و در نتیجه باعث حفظ امنیت محتویات این کوکی های امن می شود.
پیشگیری از اسپم فرم
هرزنامه فرم هنگامی رخ می دهد که برنامه های خودکار فرم های وب شما را پیدا کرده و سعی می کنند داده ها را از طریق آنها ارسال کنند تا شما را به هرزنامه ارسال کنند. هرزنامه فرم میتواند هر روز صدها یا هزاران پست فرم بی فایده را ایجاد کند. هنگامی که شما شروع به گرفتن هرزنامه می کنید، متوقف کردن آن به هدف ناامیدانه شما خواهد بود. دو روش اصلی وجود دارد:
CAPTCHA - این روش نیاز به کاربران نهایی برای خواندن متن جاسازی شده در یک تصویر و تایپ متن را به صورت موفقیت آمیز در یک فیلد فرم. این است که توسط برنامه عقب پایان تایید شده است. از آنجایی که بیشتر برنامه های اسپم نمی توانند متن را در تصاویر جاسازی شده بخوانند، با موفقیت تقریبا تمام اسپم های فرم اتوماتیک را مسدود می کند. با این حال، CAPTCHA نیازمند آن است که کاربران یک مرحله دیگر را انجام دهند و می توانند کمی آزار دهنده باشند.
جاوا اسکریپت و کوکی ها - اکثر برنامه های اسپم به صورت اتوماتیک جاوا اسکریپت را پردازش نمی کنند یا از کوکی ها استفاده می کنند. اگر فرم وب شما نیازمند جاوا اسکریپت باشد تا بتوانید فرم را به طور موفقیت آمیز ارسال کنید، رباتهای فرم قادر به انجام این کار نخواهند بود و بیشتر اسپم فرم مسدود خواهد شد. این روش کمی کمتر از CAPTCHA قابل اعتماد است؛ با این وجود، کار اضافی در مورد کاربر نهایی انجام نمی شود. توجه داشته باشید که اگر شما مایل به استفاده از روش جاوا اسکریپت هستید، باید مطمئن شوید که ارسال دلخواه به آدرس پیشفرض عملکردهای فرم شما هرگز موفق نخواهد شد - فقط ارسالهایی که پس از اجرای جاوااسکریپت شما انجام شده است باید موفق باشند.
نیاز به اعتماد را کم کنید
یک قاعده خوب این است که حداقل نیاز به اعتماد به شخص ثالث را به حداقل برسانید و اعتماد کنید.
اگر به کارکنان IT خود اعتماد نکنید، برنامه وب خود را در سرورهای خود میزبان نگذارید یا به سرور مورد استفاده دسترسی ندارید.
اگر مطمئن نیستید شخص ثالثی که وبسایت خود را میزبانی می کند، اطمینان حاصل کنید که اطلاعات فرم را در اسرع وقت رمزگذاری کنید. این کمک می کند تا اطمینان حاصل شود که داده ها در هر نقطه از متن ساده ذخیره نمی شوند و همچنین در متن ساده ثبت نشده است، بنابراین به حداقل رساندن قرار گرفتن در معرض افراد ناز در ارائه دهنده میزبانی وب می باشد. علاوه بر این، اطمینان حاصل کنید که کلید های خصوصی و رمزهای عبور مورد نیاز برای رمزگشایی داده ها، در صورت امکان، بر روی سرور های میزبان ذخیره نمی شوند، به طوری که نمی توانند داده ها را رمزگشایی کنند (و بنابراین هیچ هکرهایی که به سیستم های خود شکسته اند می توانند این کار را انجام دهند) .
اطمینان حاصل کنید که تنها کارکنان مجاز میتوانند به داده های فرم ارسال شده دسترسی پیدا کنند. در حالت ایده آل، آن همیشه باید رمزگذاری شود و تنها افراد مجاز باید توانایی رمزگشایی آن را داشته باشند.
این ها فقط چند نکته قابل توجه هستند. همانطور که خود برنامه وب خود و جریان داده ها را ارزیابی می کنید، از خودتان بپرسید: "چه کسی می تواند در هر مرحله به داده های خام و نحوه دسترسی دسترسی پیدا کند." آیا مراحل وجود دارد که در آن به مردم اعتماد می کنید که نباید مورد اعتماد قرار گیرند؟ آیا شما با استفاده از "امنیت ناگهانی" استفاده می کنید؟ اگر چنین است، دوباره ارزیابی کنید
استفاده مجدد از رمزنگاری قوی در SSL
قدرت رمزگذاری استفاده شده توسط SSL عملکرد هر دو مرورگر وب کاربرسرور حتی اگر وب سرور شما از رمزنگاری بسیار خوبی برخوردار باشد، مانند AES256، مرورگر ممکن است سطح ضعیفتری از رمزگذاری را انتخاب کند تا کارها کندتر شوند. نسخه های قدیمیتر اینترنت اکسپلورر برای انتخاب رمزنگاری ضعیف تر از علاقه به سرعت قابل توجه هستند.
شما می توانید پیکربندی وب سرور خود را تغییر دهید تا فقط سطح رمزگذاری که شما تایید می کنید می تواند برای دسترسی به سایت شما استفاده شود. برای کسب اطلاعات بیشتر، چه سطح از TLS و SSL توسط HIPAA مورد نیاز است؟
استفاده از دو شناسه ی عامل
احراز هویت دو عامل تقریبا استاندارد در سایت های بسیار امن در حال حاضر است. این به این معنی است که شما هر یک از رمز عبور و چیز دیگری (به عنوان مثال یک نشانه به دست آمده از تلفن شخصی) نیاز دارید تا هویت خود را تأیید کنید. بدون هر دو، کاربر نمی تواند وارد شود DuoSecurity را برای یک راه حل خوب که برای وب سایت های کوچک رایگان است، مشاهده کنید. Google Authenticator نیز بسیار خوب است. سعی کنید از استفاده تنها SMS (پیام های متنی) به عنوان عامل دوم دور بمانید، زیرا این دیگر امن نیست.
