Можете да видите тази публикация и в Блог на трио.

Въведение

В днешно време сигурност е модна дума». Във време, когато данните са изключително важни за защита. Забравете за златото или дори за криптовалутите за момент. Ръстът на интереса към нашите данни и следователно тяхната кражба се движи до голяма степен от Data Science, Machine Learning, Deep Learning и дори BI, и има опит с кибератаки. С толкова много лична информация за нашите клиенти, трябва да мислим повече за сигурността и как да съхраняваме този нов вид „злато“.

Политики за данни като GPDR (Общ регламент за защита на данните) имат за цел да защитят личните данни на потребителите във всяка система, която използват. Ако тяхната информация бъде споделена с друга компания и т.н., това трябва да стане с тяхното съгласие. Можем дори да видим клауза, която постановява, че компаниите трябва да уведомят потребителите за нарушение на данните в рамките на 72 часа след откриване на проблема. В този регламент санкциите могат да достигнат 20 милиона евро или 4% от годишния световен оборот.

Защитата на данните е от решаващо значение и няма по-добър начин да се илюстрира това от нарушението на данните на Equifax, което засегна личната информация на приблизително 147 милиона души през септември 2017 г. Equifax е една от трите най-големи агенции за отчитане на потребителски кредити в САЩ и претърпя огромен пробив в данните заради малък проблем, който можеше лесно да бъде коригиран. Повече за това след малко. В резултат на техния скандал, Equifax ще трябва да плати до $700 милиона глоби като част от споразумение с федералните власти за това нарушение на данните.

Друга компания откри хакер, който е откраднал почти 250 000 долара продукти, без да плати за тях. Тази компания току-що откри измамата в следващия финансов цикъл (един месец по-късно), където можеха да видят липса на пари. За съжаление те решиха да инвестират в сигурност едва след тази ситуация. Разказвам ви тези истории, за да ви илюстрирам сериозността на тези ситуации, защото всяко нарушение на данните може да засегне вашата компания по начини, които никога не искате.

В тази публикация ще разгледаме основите на сигурността, за да защитим вашето уеб приложение или услуга. Тези концепции могат да се прилагат във всяка уеб услуга освен езици, но моите примери ще бъдат по-фокусирани върху Javascript (Node.JS) с Express и Sequelize ORM.

1. Не се доверявайте на клиента си

Няма начин да разберем дали нашите потребители имат добри намерения или не, не можем да се доверим на данни, въведени от нашите клиенти. Това означава, че трябва да проверяваме всеки вход. Можем да го направим с черен или бял списък.

В черен списък имаме лоши въведени данни, които се считат за неприемливи като потребителски въведени данни. В белия списък имаме входове, които позволяваме да съществуват. Нека да разгледаме един пример.

Знаем, че eval() е функция, която изпълнява низове като команди в Javascript. Разбира се, потребител с добри намерения не би използвал този вид съдържание като имейл. Така че ще заменим всеки eval() да бъде празен.

Това може да бъде полезно, но при всяка нова заплаха трябва да проверяваме кода си и да го почистваме. Така че за този етап белите списъци са по-надеждни от черните списъци. Имаме страхотни библиотеки, които ни помагат да създаваме бързи проверки на бели списъци в нашите маршрути, например Hapi/JOI. Вижте този пример, където проверяваме входовете за удостоверяване на потребителя:

Този пример по-горе е страхотен, защото тази библиотека ще ни гарантира две неща:

  1. Добър бял списък с добри стандарти. Ако въведеното не отговаря на нашите стандарти, новата грешка()ще бъде задействана.
  2. Защита срещу въвеждане на параметри, което означава, че хакерът се опитва да изпрати повече параметри към нашите маршрути. Ако съществува различен параметър освен имейл и парола, новата грешка()ще бъде задействана;

Относно инжектирането на параметри, веднъж станах свидетел на голяма компания, която беше хакната с тази техника от етичен хакер. Това бяха неговите стъпки:

  • Той намери страницата на профила;
  • Той видя, че страницата на профила използва заявката PATCH, т.е. приложението изпраща заявка за актуализиране на данните в профила;
  • Той се опита да добави някои нови параметри към тази заявка и един от тях беше isAdmin: true;
  • Редовният му потребител се превърна в администратор.

В нашия пример единствените разрешени параметри са имейл и парола и те трябва да отговарят на нашите стандарти. Не забравяйте да използвате бели списъци, те са много полезни! Те могат да помогнат срещу инжектиране на параметри и XSS.

2. Използвайте bind-params във вашите SQL изрази

Вероятно сте чували за SQL инжекциите и колко мощни могат да бъдат те. Ако не сте чували за тях, предлагам ви да прочетете за тях. Освен това проверете „OWASP Top Ten Attacks“. Но по същество нападателят се опитва да промени заявките, които системата прави, и получава достъп до цялата база данни.

Никога няма да забравя деня, в който говорих за нарушение на SQL Injection с един от моите колеги. Той ме предизвика да получа достъп до система, която той направи за негов приятел чрез SQL Injection атака. Тази система не използваше параметрите за свързване, така че получих администраторския потребител и поставих в полето за парола добре позната команда за SQL инжектиране, за да заобиколя паролата за всеки потребител, и готово! Имам администраторски достъп. Сега, като си помислих за тази история, се сетих, че трябваше да се обзаложа на една бира с него.

Най-простото решение е да използвате параметри за свързване. Параметрите на свързване променят стойностите вътре в базата данни, което прави невъзможно прекъсването на заявката и промяната на друга. В днешно време повечето от ORM използват параметри за свързване по подразбиране, но обърнете внимание да не правите персонализирана заявка и да я изпълните без параметри за свързване. Например, в Node.JS + Sequelize, ако искаме да използваме персонализирана заявка, можем да направим нещо като:

Изображението по-горе показва два метода, първият метод е пример с персонализирана заявка без параметри за свързване, а вторият е такъв с персонализирана заявка, използваща параметри за свързване. Може би сте се досетили правилно, вторият метод е по-добрият. Ако трябва да използвате персонализирани заявки, моля, не забравяйте да използвате параметрите за свързване. Освен това се уверете, че вашият ORM също ги използва. Знам, че Sequelize го прави, като наблюдава регистрационните файлове и знам, че най-известните ORM ги използват, но ако сте от хората, които обичат да изпробват нови технологии и библиотеки, това е добра точка да започнете своето решение, ако този ORM е добър или не.

Следователно не използвайте никакъв вид заявка без параметри за свързване. SQL Injection се смята за една от най-известните от първите десет атаки срещу уеб приложения и е открита през 90-те години. И така, това показва колко пренебрегнати са били повечето разработчици и инженери. Все още не знам защо не учим разработчиците да използват параметри за свързване от първия клас, за да се свързват с базата данни и да правят заявки.

3. Не излагайте чувствителни данни

Колко често вашата уеб услуга обработва чувствителни данни? Ако никога не сте си задавали този въпрос, вероятно вашата уеб услуга разкрива по-чувствителни данни, отколкото си мислите.

Първата стъпка е да приложите SSL/TLS сертификат към нашата уеб услуга и да го използвате като връзка по подразбиране. Вече не можем да приемаме HTTP връзки за системи, които използват нашата лична информация! Този сертификат гарантира, че имаме криптирана връзка между сървъри и клиенти, което почти смекчава „надушването на данни“ от трета страна („атака на човек по средата“).

След това се запитайте: как бихме могли да помогнем на хакерите да получат достъп до нашата информация? Показване на системни грешки за тях! Грешките понякога могат да покажат много чувствителна информация, като например системата на базата данни, имена на таблици, имена на полета, имена на ограничения, език (Javascript, Java, Python и т.н.), а понякога дори можем да видим информация за хостинг и пароли. Когато това се случи, това дава на хакерите добро ръководство за изследване на известните пробиви в сигурността на технологията, системите, рамките и езика, с които работи вашата уеб услуга.

Не мога да подчертая достатъчно тази една точка: не показвайте грешки на потребителите. Трябва да ги прихванем и да ги изпратим на програми като Rollbar или Sentry. Тези програми имат страхотна поддръжка за много езици, да не говорим, че е доста лесно да конфигурирате вашите изключения, за да показват съобщение по подразбиране на потребителя и да изпращат системната грешка до тези програми за проследяване.

В крайна сметка е най-добре да покажете на потребителя съобщение за грешка по подразбиране или описано удобно за потребителя съобщение за грешка (това зависи от вашата уеб услуга и вашите бизнес правила), вместо да показвате цялата системна грешка. Не знаете какво може да е вашето съобщение за грешка по подразбиране? Просто опитайте: „Вътрешна грешка на сървъра“. Много по-добре и надеждно е, когато системата го показва, а не цялата системна грешка.

4. Проверете вашите библиотеки на трети страни

„Equifax ще плати до 700 милиона долара глоби“. Можете ли да си представите, че вашата компания е отговорна за огромно нарушение на данните като това? И така, какво се случи с Equifax? Е, това не е сложна история за разказване.

Equifax имаше система, която използва Apache Struts. Два месеца преди атаката Apache Struts обяви нова корекция за коригиране на конкретна уязвимост. Два месеца по-късно хакерът използва тази уязвимост, което означава, че „Equifax не е актуализирал своите системи“.

Това беше резултатът:

За да предотвратим този вид проблем, трябва да разгледаме нашите библиотеки на трети страни. В днешно време е почти невъзможно да създадете каквото и да е приложение, без да използвате библиотека или рамка на трета страна. Но човек трябва да попита, кой е направил тази библиотека? Колко добре се управлява?. Ние сме хора и правим грешки. Следователно, като разработчик, ваша отговорност е да управлявате интеграциите, които използвате. Това означава да оцените техните рискове и да разберете потенциалните ефекти, които може да има върху вашата система, и да сте в крак с всички актуализации.

Има фантастичен инструмент, наречен „Snyk“, който държи разработчиците бдителни за повреди, уязвимости и проблеми с вашите интеграции. Snyk има огромна база данни с много сътрудници и когато открият нова уязвимост, те предупреждават всичките си клиенти, които са задали Snyk в своите приложения. През повечето време те поправят новите уязвимости автоматично с една команда, която трябва да изпълните. Освен това Snyk ви предупреждава чрез имейла ви.

Snyk е наистина невероятен! Аз лично харесвам как компаниите работят усилено, за да осигурят значителна стойност, особено що се отнася до сигурността. Ето защо те получиха „повече от $1 милиард оценка“. Те също имат безплатни планове и планове на цени. В момента използвам безплатния план за личните си проекти и те поддържат много езици и мениджъри на пакети.

5. Задайте някои ограничения за потребителя

Аз съм много ентусиазиран относно криптовалутите и биткойните и говоря повече за „използването на блокчейн в блога на триото“. Спомням си, че бях свидетел на падането на борсата, защото цената на биткойн се покачваше твърде бързо. След като собственикът загуби много пари, те решиха да инвестират повече в архитектурата и въведоха нова функция в своите API: ограничения за клиента.

В борсата, за да се гарантира добро представяне, те изпращат нов резултат всяка минута. Ако поискате един и същи маршрут няколко пъти в същата минута, ще получите същия кеширан резултат. Това е чудесен начин да осигурите повече производителност и да намалите шансовете вашият сървър да падне. Разбира се, трябва да проучим и анализираме въздействията върху бизнеса, като кешираме отговора на всяка минута.

Освен това използването на слой за защита на услугата ви от DDoS атаки като Cloudflare е страхотна опция и можем да комбинираме тяхното решение с добра архитектура на нашите API. Това всъщност направи тази борса, те комбинираха кеширан резултат с Cloudflare DDoS защита.

6. Прочетете раздела за сигурност в ръководството на вашата библиотека

Явно поколение след поколение четем все по-малко. Освен това се сблъскваме с проблеми с обръщането на внимание за продължителни периоди от време. Като софтуерен инженер знам, че „търпение“, „внимание“ и „четене“ са ключови думи в ежедневието ни. Така че е особено важно да дисциплинираме се и четем документацията от нашите рамки и трети библиотеки, включително „Секцията за сигурност“.

Използвайки Express, забелязах, че имаме раздел, наречен „Теми за напреднали“ и „Най-добри практики за сигурност“.

Това е страхотно, но знам, че повечето софтуерни инженери, които са инсталирали Express, не са чели документацията на Express и вероятно никога не са си направили труда да се гмурнат в раздела „Теми за напреднали“, още по-малко в страницата „Най-добри практики за сигурност“.

За моя изненада, когато реших да внедря Express в един от моите API, видях този раздел и открих, че Express предлага чудесна документация за това как да защитите вашата уеб услуга с Express. С тази документация успях да се науча как да използвам Express по начин, който не компрометира системата ми в бъдеще.

7. Не бъдете параноични и не пренебрегвайте изучаването на сигурността

След като проучих за сигурността на моите приложения и уеб услуги, започнах малко да се побърквам! Не можах да завърша задачите си навреме, защото мислех твърде много за всички потенциални пробиви в сигурността на моя код. Трябва да помним, че дори големи организации като ЦРУ, Sony, eBay, Yahoo, JP Morgan Chase, Netshoes, Dropbox, YouTube и други, са били хакнати. Имайки предвид това, не бъдете толкова параноични относно услугите си, в края на краищата, ако хакерите наистина искат да хакнат приложението ви, вероятно ще намерят начин. Просто е в природата им. Въпросът е: колко време ви трябва, за да установите, че хакерът е заобиколил бариерите ви за сигурност? С добри регистрационни файлове и силна стратегия за предупреждения можем да идентифицираме нарушенията по-рано и по този начин да действаме по-бързо.

Това не е извинение да си казвате, че е безсмислено, защото хакерите ще спечелят. Разработчиците и професионалистите по киберсигурност работят за изграждането на възможно най-много стени, лабиринти, капани и други защити, от които хакерите да се обезсърчат и да оставят системата си на мира. Затова е най-добре да направите работата на хакера възможно най-трудна с надеждата, че ще премине към следващата си цел.

Освен това не пренебрегвайте изучаването на сигурността. Тази публикация обхваща най-основните техники за сигурност, които трябва да научим в колежа или в уроци за начинаещи в Интернет. Повечето разработчици не се интересуват от защитата на своите услуги на основно ниво. Това е проблем.

Затова не бъдете параноични, но не пренебрегвайте изучаването и инвестирайте време в защита на приложенията си. Добър ресурс за изучаване е страницата на OWASP, особено страницата с проекти. Можете да изтеглите проектите „Lab“, за да ги стартирате локално и да ги хакнете сами. Тези проекти имат пробиви в сигурността, реализирани нарочно. Толкова е смешно да се учиш по този начин, когато можеш да си хакер и софтуерен инженер, опитващ се да спре хакера (вас) в един и същи момент. Проектът Node.JS, който трябва да научите, се нарича NodeGoat и има урочно ръководство, което да ви помогне да хакнете и защитите проект. Има и други проекти на други езици, струва си да ги разгледате.

Единственият начин наистина да намерите начини да спрете хакер е да мислите като такъв и да разбиете собствената си система. Това е основната идея на теста за проникване

8. Дневници и мониторинг

Има някои ситуации, в които трябва да одитираме нашите данни, за да отговорим на някакви въпроси като: „Кой редактира този ред?“, „Какво прави нашия сървър твърде бавен?“ и т.н.

Не можем да отговорим на тези въпроси, ако нямаме добри регистрационни файлове. Това може да бъде опасно за всяка компания, включително ако компанията трябва да идентифицира потребител с лоши намерения. Представете си следната ситуация: Някой е хакнал вашата уеб услуга, за да обработва плащания от клиенти. Вашият шеф пита: „Как хакерът премина през нашите бариери за сигурност?“

Това може да е труден въпрос, ако нямате добри регистрационни файлове, с които да започнете разследването си. Съмнявам се, че някой ръководител се опитва да чуе извинението, че не е имало никакви регистрационни файлове и следователно няма начин да се знае. Това няма да ви отведе много далеч. Така че не пренебрегвайте вашите регистрационни файлове и се уверете, че имате система, която да ги следи.

Заключение

Надявам се, че тази публикация ви помогна да ви запозная с някои основни стъпки за защита на вашата уеб услуга и вашето уеб приложение. Важно е да започнем да мислим за киберсигурността с нашите уеб приложения и да прилагаме това, което научаваме чрез изследвания и практика, за да гарантираме по-безопасна система.