6 Riziká webového backendu, ktoré treba brať do úvahy pri vývoji

Prijmite opatrenia vo vývoji, aby ste sprísnili a udržali svoj webový backend v bezpečí.


Malé podniky, banky a mnohé priemyselné odvetvia závisia od webových aplikácií. Od vytvorenia webovej aplikácie je veľmi dôležité mať k dispozícii protokoly na kontrolu zraniteľností, pretože vývoj sa vyvíja, aby sa predišlo narušeniu bezpečnosti, únikom údajov a finančným problémom..

Najnebezpečnejšie webové útoky sú útoky, ktoré sa vyskytujú na strane servera, kde sa ukladajú a analyzujú údaje.

Čo je Backend?

Webová aplikácia je rozdelená na dve časti – Frontend a Backend.

  • Klientske rozhranie je klientskou časťou, s ktorou používateľ interaguje. Spravidla je vytvorený pomocou HTML, CSS a Javascript.
  • Backend je na strane servera. Je to v podstate to, ako aplikácia funguje, používa obchodnú logiku, zmeny a aktualizácie. Niektoré z populárnych technických zásobníkov na strane servera zahŕňajú PHP, NodeJS, Java, Ruby, C, Python, databázu, bezpečnosť (autentifikácia, riadenie prístupu atď.), Štruktúru a správu obsahu..

Trochu pripomenutie predtým, ako začneme – autentifikácia, riadenie prístupu & správa relácií

Je pre nás bežné zamieňať si podmienky. Vysvetlite to teda rýchlo:

  • Autentifikácia sa týka preukázania totožnosti používateľa (napr. Heslo, užívateľské meno, bezpečnosť otázok, odtlačky prstov)
  • Kontrola prístupu sa týka toho, čo môže užívateľ získať prístup k aplikácii. Presadzuje zásady, podľa ktorých používatelia nemôžu konať mimo svojich zamýšľaných povolení.
  • Správa relácií sa týka odpovedí a transakcií transakcií spojených s rovnakým používateľom. Je to mechanizmus výmeny, ktorý sa používa medzi používateľom a aplikáciou po úspešnom overení.

Pozrime sa na nasledujúce, aby sme zaistili lepšiu webovú bezpečnosť.

Vstrekovacie nedostatky

Od roku 2010 spoločnosť OSWAP klasifikovala injekcie ako najnebezpečnejšie riziko webových aplikácií.

Chyby pri vstrekovaní umožňujú používateľovi poskytovať údaje obsahujúce kľúčové slová, ktoré upravujú správanie dopytov vytvorených v databáze. Predpokladajme napríklad, že máme skript SQL, ktorý skontroluje, či sa v databáze zhoduje položka.

uname = request.POST [‘username’]
passwd = request.POST [‘heslo’]
sql = "VYBERTE ID OD používateľov KDE username = ‘" + UNAM + "’AND password =’" + passwd + "’"
database.execute (SQL)

Útočník teraz môže manipulovať s heslom pomocou injekcie SQL, napríklad zadaním hesla „ALEBO 1 =“, čo vedie k nasledujúcemu dotazu SQL:

sql = "VYBERTE ID OD používateľov, KDE meno používateľa = ” A heslo = ‘heslo’ ALEBO 1 = ‘1’

Útočník tak získa prístup k všetkým tabuľkám používateľov v databáze, pričom heslo je vždy platné (1 = „1“). Ak sa prihlásia ako správca, môžu vykonať požadované zmeny.

Ako tomu zabrániť?

Je to veľmi EASY aby sa predišlo chybám pri vstrekovaní.

Najlepším a jednoduchým spôsobom, ako overiť, či neexistujú chyby pri vstrekovaní, je dôkladná manuálna kontrola zdrojového kódu, aby sa skontrolovalo, či sú dotazy v databáze vykonávané prostredníctvom pripravených príkazov. Môžete tiež použiť nástroje na kontrolu zraniteľnosti.

Mali by ste tiež urobiť nasledujúce.

  • Použite ORM (nástroje objektového relačného mapovania).
  • Uniknite zo všetkých vstupov. Pole s dátumom by nikdy nemalo mať v sebe uložené žiadne položky okrem dátumov.
  • Izolujte svoje údaje tak, aby sa na danom mieste uchovávali iba veci, ku ktorým by sa malo pristupovať z daného miesta.
  • Napíšte správne chybové kódy. Nenechajte svoju databázu ani svoj backend príliš podrobný.

Troy Hunt dostal skvelý kurz o SQL vstrekovaní. V prípade záujmu to môžete preskúmať.

Zlomená autentifikácia

Ako už bolo uvedené, autentifikácia sa zaoberá poskytovaním poverovacích údajov. Je to frontová obrana proti neobmedzenému prístupu. Zlá implementácia a nerešpektovanie bezpečnostnej politiky však môžu viesť k narušeniu autentifikácie.

Nefunkčné overovanie sa deje väčšinou tromi vzormi:

  • Výplň poverenia: kde má útočník zoznam platných používateľských mien a hesiel a môže automatizovať útok na zistenie platnosti poverení.
  • Bruteforce útok: kde aplikácia umožňuje slabé heslá pre používateľov alebo správcov.
  • Únos únosov: kde aplikácia odhalí ID relácie, URL alebo sa po prihlásení neotáča.

Útočník môže vo všetkých prípadoch získať prístup k dôležitému účtu a je závislý na podnikaní, ktoré môže spôsobiť pranie špinavých peňazí, krádež identity alebo odhaliť legálne chránené a citlivé informácie..

Ako tomu zabrániť?

Pred implementáciou autentifikačného systému sa opýtajte sami seba – čo by mohol útočník dosiahnuť, ak by bol narušený autentifikačný systém?

A podľa odpovede môžete urobiť nasledovné.

  • Implementujte viacfaktorové overovanie, aby ste zabránili automatizovaným útokom.
  • Povzbudiť (alebo prinútiť) používateľa, aby prijal dobrú politiku hesiel.
  • Obmedziť počet neúspešných prihlásení.
  • Použite efektívny algoritmus hash. Pri výbere algoritmu zvážte maximálnu dĺžku hesla.
  • Otestujte systém časového limitu relácie a uistite sa, že token relácie je po odhlásení zneplatnený.

Kontrola prerušeného prístupu

Existuje kontrola prístupu, aby sa zabezpečilo, čo oprávnený používateľ môže robiť. Základom pravidiel riadenia prístupu alebo prístupu sú autentifikácia a správa relácií. Ak však tieto pravidlá nie sú správne stanovené, môže to viesť k závažným problémom.

Medzi bežné nedostatky v kontrole prístupu patrí:

  • Nesprávna konfigurácia CORS, ktorá umožňuje neoprávnený prístup k rozhraniu API.
  • Manipulácia s metaúdajmi na priamy prístup k metódam.
  • Nútené prehliadanie: Útočník vyskúša webovú adresu, upraví cesty (napr. Http: //website.domain/user/ na http: //website.domain/admin) a môže dokonca objaviť dôležité súbory..

Ako tomu zabrániť?

Chyby s prerušeným prístupom sa väčšinou vyskytujú v nevedomosti o základných požiadavkách efektívneho riadenia prístupu.

  • Zakázať v predvolenom nastavení okrem verejných zdrojov.
  • Vypnite zoznam adresárov servera a uistite sa, že nie sú k dispozícii záložné súbory.
  • Prístup k rozhraniu Rate Limit API na zníženie vplyvu automatických útokov.
  • Po odhlásení na zadnej strane zrušte platnosť tokenov JWT.

Expozícia dát

Expozícia údajov, ktorá sa tiež nazýva narušenie údajov, predstavuje hrozbu, ktorú ohrozujú podniky a ich klientov.

Vyskytuje sa, keď aplikácia dostatočne nechráni informácie, ako sú poverovacie údaje alebo citlivé údaje, ako sú kreditné karty alebo zdravotné záznamy. Viac ako 4000 záznamov je každú minútu.

Dopad na podnikanie je z finančnej stránky veľký: Podľa agentúry EUR môže priemerné porušenie stáť 3,92 milióna USD IBM.

Ako tomu zabrániť?

Ako vývojár backendu by ste sa mali opýtať, aké informácie potrebujú ochranu.

A potom zabrániť takýmto nedostatkom:

  • Šifrovať citlivé údaje: Pre údaje v RESTe zašifrujte všetko. Pri prenose údajov nezabudnite použiť zabezpečené brány (SSL)
  • Identifikujte údaje, ktoré si vyžadujú mimoriadnu ochranu, a obmedzte prístup len na skupinu oprávnených používateľov iba vynútením šifrovania na základe kľúča.
  • Vyvarujte sa slabému šifrovaciemu algoritmu: používajte aktuálne a silných algoritmov.
  • Majte zabezpečený plán zálohovania.

Nezabezpečená deserializácia

Serializácia a deserializácia sú koncepty používané pri konverzii údajov v objektovom formáte na uloženie alebo odoslanie do inej aplikácie. Serializácia spočíva v prevode údajov v objektovom formáte, ako je XML alebo JSON, aby boli použiteľné. Deserializácia je len opačný proces.

Útoky proti deserializátorom môžu viesť k útokom na odmietnutie služby, riadeniu prístupu a útokom na vzdialené vykonanie kódu (RCE), ak existujú triedy, ktoré je možné zmeniť tak, aby zmenili správanie.

Druhý príklad top 10 dokumentu OWASP poskytuje dobrú ilustráciu serializátora objektov PHP:

A: 4: {i: 0; i: 132; i: 1, s: 7:"Mallory"; I: 2; s: 4:"užívateľ";
i: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Toto je supercookie, ktoré obsahuje informácie ako ID užívateľa, úroveň používateľa a hashované heslo.

Útočník môže zmeniť serializovaný objekt, aby získal prístup k administrátorským oprávneniam:

A: 4: {i: 0, I: 1; i: 1, s: 5:"Alice"; I: 2; y: 5:"admin";
i: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Ako tomu zabrániť?

Je nevyhnutné neakceptovať serializované objekty z nedôveryhodných zdrojov.

Mali by ste tiež:

  • Nikdy neverte vstupu používateľa.
  • Overenie údajov: Ak je vaša aplikácia okrem reťazca, pred použitím ju skontrolujte
  • Pomocou kontroly skontrolujte, či sa údaje nezmenili. Je užitočné posielať údaje medzi dvoma dôveryhodnými zdrojmi (napr. Ukladaním údajov na strane klienta).

Server XSS

Server XSS (Skriptovanie viacerých stránok) je typ injekcie, keď útočník používa webovú aplikáciu na odosielanie škodlivého kódu rôznym používateľom. Vyskytuje sa, keď útočník zverejní niektoré spracované údaje obsahujúce škodlivý kód, ktorý aplikácia ukladá. Táto zraniteľnosť je na strane servera; prehliadač jednoducho odpovie.

Napríklad vo fóre sa príspevky používateľov ukladajú do databázy, často bez overenia. Útočníci využívajú túto príležitosť na pridávanie príspevkov so škodlivými skriptmi. Následne dostanú ostatní používatelia tento odkaz e-mailom alebo uvidia príslušný príspevok a kliknú naň.

Ako tomu zabrániť?

Po primárnej identifikácii všetkých operácií, ktoré sú potenciálne ohrozené XSS a ktoré je potrebné chrániť, by ste mali zvážiť nasledujúce.

  • Potvrdenie zadania: skontrolujte zadanú dĺžku, použite porovnávanie regulárnych výrazov a povoľujte iba určitú skupinu znakov.
  • Overiť výstup: Ak aplikácia skopíruje do svojich odpovedí na akúkoľvek položku údajov, ktorá pochádza od niektorého používateľa alebo tretej strany, tieto údaje by mali byť kódované HTML, aby sa dezinfikovali potenciálne škodlivé znaky..
  • Povoliť limit HTML: napríklad, ak máte blogový systém komentárov, povoľte iba používanie určitých značiek. Ak je to možné, použite vhodný rámec na označovanie HTML dodávané používateľom, aby ste sa uistili, že neobsahuje prostriedky na spustenie skriptu JavaScript..

záver

Fáza vývoja je rozhodujúca pre bezpečnosť webových aplikácií. Mali by ste zvážiť zahrnutie skenera bezpečnostných zraniteľností do životného cyklu vývoja, takže identifikované problémy sú vyriešené pred výrobou.

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