6 рискове за сигурността на уебсайта, които трябва да се вземат предвид при развитието

Вземете мерки в развитието си, за да втвърдите и запазите уеб страницата си защитена.


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

Най-опасните уеб атаки са тези, които се случват от страна на сървъра, където се съхраняват и анализират данни.

Какво е Backend?

Уеб приложение е разделено на две части – Frontend и Backend.

  • Frontend е от страна на клиента, това е частта, с която потребителят взаимодейства. Обикновено той е изграден с HTML, CSS и Javascript.
  • Връзката е от страна на сървъра. Основно е как работи приложението, прилага бизнес логиката, промените и актуализациите. Някои от популярните технологични стекове от страна на сървъра включват PHP, NodeJS, Java, Ruby, C, Python, база данни, сигурност (удостоверяване, контрол на достъпа и т.н.), структура и управление на съдържанието.

Малко напомняне, преди да започнем – удостоверяване, контрол на достъпа & управление на сесията

Обичайно е да бъркаме термините. Затова нека го изясним бързо:

  • Удостоверяването се отнася до доказване на самоличността на потребителя (напр. Парола, потребителско име, сигурност, въпроси, пръстови отпечатъци)
  • Контролът на достъпа се отнася до това, което потребителят може да има достъп до приложението. Той налага политиката, според която потребителите не могат да действат извън предвидените им разрешения.
  • Управлението на сесиите се отнася до отговори и транзакции на заявки, свързани с един и същ потребител. Това е механизъм за обмен, който се използва между потребителя и приложението, след като той успешно се удостовери.

Нека да проучим следното за по-добра бек-енд сигурност в мрежата.

Недостатъци на инжектиране

От 2010 г. OSWAP класифицира инжектирането като # 1 най-опасен риск за уеб приложение.

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

uname = request.POST [‘потребителско име’]
passwd = request.POST [‘парола’]
sql = "ИЗБЕРЕТЕ ID от потребители, където потребителско име = ‘" + uname + "’И парола =’" + ако съществува + "”"
database.execute (SQL)

Сега нападателят може да манипулира полето за парола, като използва инжекция SQL, например като въведе паролата „ИЛИ 1 =“ 1, което води до следната SQL заявка:

sql = "ИЗБЕРЕТЕ ID от потребители, където потребителско име = ” И парола = ‘парола’ ИЛИ ​​1 = ‘1’

По този начин нападателят може да получи достъп до всички потребителски таблици на базата данни, като паролата е винаги валидна (1 = ‘1’). Ако влезе като администратор, те могат да правят всякакви промени, които той иска.

Как да го предотвратим?

Много е ЛЕСНО за да се избегнат недостатъци на инжектирането.

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

И вие също трябва да направите следното.

  • Използвайте ORMs (Инструменти за релационно картографиране на обекта).
  • Избягвайте всички входове. В полето за дата никога не трябва да се съхранява нищо друго освен тях.
  • Изолирайте данните си, така че на това място да се задържат само нещата, които трябва да бъдат достъпни от дадено местоположение.
  • Напишете добри кодове за грешки при работа. Не правете вашата база данни или резервния си текст твърде многословни.

Трой лов имам блестящ курс по SQL инжекция. При интерес можете да проучите това.

Прекъснато удостоверяване

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

Счупеното удостоверяване се случва най-вече по три модела:

  • Пълнители за пълномощия: където нападателят има списък с валидни потребителски имена и пароли и може да автоматизира атаката, за да установи, че идентификационните данни са валидни.
  • Bruteforce атака: когато приложението позволява слаби пароли за потребители или администратори.
  • Отвличане на сесия: когато приложението излага идентификационен номер на сесията, URL адрес или не се върти след влизане.

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

Как да го предотвратим?

Преди да внедрите системата за удостоверяване, се запитайте – какво може да постигне атакуващ, ако системата за удостоверяване е компрометирана?

И според отговора можете да направите следното.

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

Прекъснат контрол на достъпа

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

Общите недостатъци в контрола на достъпа включват:

  • Неправилна конфигурация на CORS, която позволява неоторизиран достъп до API.
  • Манипулиране на метаданни за директен достъп до методи.
  • Принудително сърфиране: Нападателят ще изпробва URL адрес, ще променя пътища (напр., Http: //website.domain/user/ до http: //website.domain/admin) и дори може да открие важни файлове.

Как да го предотвратим?

Най-вече нарушените недостатъци на достъпа възникват поради незнание относно основните изисквания за ефективно управление на достъпа.

  • Отказ по подразбиране, с изключение на публичните ресурси.
  • Деактивирайте списъка на директорията на сървъра и се уверете, че резервните файлове не присъстват.
  • Ограничете достъпа до API за намаляване на въздействието на автоматизирани атаки.
  • Невалидни JWT маркери след излизане откъм страницата.

Излагане на данни

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

Това се случва, когато приложението не защитава по подходящ начин информация като идентификационни данни или чувствителни данни като кредитни карти или здравни записи. Повече от 4000 записа са нарушена всяка минута.

Въздействието върху бизнеса е голямо от финансова страна: средно нарушение може да струва 3,92 милиона щатски долара, според IBM.

Как да го предотвратим?

Като програмист за гръб, трябва да попитате каква е информацията, която се нуждае от защита.

И тогава, за да предотвратите подобни недостатъци:

  • Шифроване на чувствителни данни: За данни в REST шифровайте всичко. За данни в транзит не забравяйте да използвате сигурни шлюзове (SSL)
  • Идентифицирайте данните, които изискват допълнителна защита и ограничете достъпността само до куп законни потребители само чрез налагане на криптиране въз основа на ключ.
  • Избягвайте слаб алгоритъм за криптиране: използвайте актуални и силни алгоритми.
  • Имайте сигурен резервен план.

Несигурна десериализация

Сериализацията и десериализацията са понятия, използвани при преобразуване на данни в обектен формат, които се съхраняват или изпращат до друго приложение. Сериализацията се състои в преобразуване на данни в обект формат като XML или JSON, за да ги направи използваеми. Десериализацията е просто обратният процес.

Атаките срещу десериализатори могат да доведат до отказ на услуга, контрол на достъпа и атаки за изпълнение на отдалечен код (RCE), ако има класове, които могат да бъдат модифицирани, за да променят поведението.

Вторият пример на документа за топ 10 на OWASP предоставя добра илюстрация на сериализатор на PHP обекти:

а: 4: {I: 0; I: 132; и: 1; е: 7:"Малъри"; И: 2; и: 4:"потребител";
I: 3; е: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Това е супер-бисквитка, съдържаща информация като идентификатор на потребител, ниво на потребителя и хеширана парола.

Нападателят може да промени сериализирания обект, за да получи достъп до администраторски права:

а: 4: {I: 0; I: 1; I: 1; е: 5:"Алис"; И: 2; и: 5:"администратор";
I: 3; е: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Как да го предотвратим?

Важно е да не приемате сериализирани обекти от недоверие.

Вие също трябва:

  • Никога не се доверявайте на потребителския вход.
  • Валидиране на данни: Ако приложението ви, с изключение на низ, се уверете, че е низ, преди да го използвате
  • Използвайте чек, за да сте сигурни, че данните не са променени. Полезно е да изпращате данни между два доверени източника (напр. Съхраняване на данни от страна на клиента).

Сървър XSS

Сървър XSS (Скрипт на място) е вид инжекция, когато нападател използва уеб приложение, за да изпрати злонамерен код до различни потребители. Това се случва, когато нападателят публикува някои изработени данни, съдържащи злонамерен код, който приложението съхранява. Тази уязвимост е от страна на сървъра; браузърът просто дава отговор.

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

Как да го предотвратим?

След първичната идентификация на всички операции, които потенциално са изложени на риск от XSS и които трябва да бъдат защитени, трябва да имате предвид следното.

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

заключение

Фазата на разработка е от решаващо значение за сигурността на уеб приложенията. И трябва да помислите за включване на скенер за уязвимост на защитата в жизнения цикъл на разработката, така че идентифицираните проблеми са отстранени преди производството.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map