Die probleem met webtoepassings is dat hulle openlik blootgestel word aan miljarde internetgebruikers, waarvan baie die veiligheidsmaatreëls wil verbreek – om watter redes ook al..
In die vroeë dae van die internet was een van die mees algemene aanvalmetodes basiese, eenvoudige brute krag. Bots het gewoonlik hierdie aanvalle uitgevoer – of persone met baie vrye tyd – wat 'n miljoen kombinasies van gebruikersname en wagwoorde probeer het totdat hulle een gevind het wat toegang tot die teikentoepassing sou verleen..
Danksy wagwoordbeleide, beperkte aanmeldpogings en captchas is daar nie meer 'n bedreiging vir brute magte nie. Maar kubermisdadigers hou daarvan om nuwe uitbuitings te ontdek en om dit te gebruik om nuwe soorte aanvalle uit te voer. Hulle het lank gelede agtergekom dat teksvelde op toepassings of webblaaie uitgebuit kan word deur 'of onverwagte teks' daarin in te voer wat die toepassing sal dwing om iets te doen wat dit nie sou doen nie. Op die manier het die sogenaamde inspuitaanvalle die toneel binnegekom.
Inspuitingsaanvalle kan nie net gebruik word om by 'n toepassing aan te meld sonder om gebruikersnaam en wagwoord te ken nie, maar ook om privaat, vertroulike of sensitiewe inligting bloot te lê, of selfs om 'n hele bediener te kaap. Daarom is hierdie aanvalle nie net 'n bedreiging vir webtoepassings nie, maar ook vir die gebruikers wie se data op daardie toepassings lê, en in die ergste gevalle, vir ander gekoppelde toepassings en dienste..
1 Kode inspuiting
5 XPath inspuiting
7 CRLF inspuiting
9 LDAP inspuiting
9.1 Voorkoming van inspuitings
Kode-inspuiting is een van die algemeenste soorte inspuitaanvalle. As aanvallers die programmeringstaal, die raamwerk, die databasis of die bedryfstelsel wat deur 'n webtoepassing gebruik word, ken, kan hulle kode via teksinvoervelde inspuit om die webbediener te dwing om te doen wat hulle wil.
Hierdie vorme van inspuitingsaanvalle is moontlik op toepassings wat nie validering van insetdata het nie. As 'n teksinvoerveld gebruikers toelaat om in te voer wat hulle wil, kan die toepassing moontlik benut word. Om hierdie aanvalle te voorkom, moet die toepassing soveel beperk as wat die insetgebruikers toegelaat word om in te gaan.
Dit moet byvoorbeeld die hoeveelheid verwagte data beperk, die dataformaat nagaan voordat dit aanvaar word, en die stel toegelate karakters beperk.
Die kwesbaarhede met die kode-inspuiting kan maklik gevind word deur net die teksinvoer van 'n webtoepassing met verskillende soorte inhoud te toets. As dit gevind word, is die kwesbaarhede matig moeilik om te benut. Maar wanneer 'n aanvaller daarin slaag om een ​​van hierdie kwesbaarhede te benut, kan die impak die verlies van vertroulikheid, integriteit, beskikbaarheid of toepassingsfunksionaliteit insluit..
Op dieselfde manier as kode-inspuiting, voeg hierdie aanval 'n SQL-skrif in – die taal wat deur die meeste databasisse gebruik word om navraagbewerkings uit te voer – in 'n teksinvoerveld. Die skrip word na die toepassing gestuur, wat dit direk in sy databasis uitvoer. As gevolg hiervan, kan die aanvaller deur 'n aanmeldskerm gaan of gevaarliker dinge doen, soos om sensitiewe data direk vanaf die databasis te lees, databasisdata te verander of te vernietig of administreerders op die databasis uit te voer..
PHP- en ASP-toepassings is geneig tot SQL-inspuitingsaanvalle as gevolg van die ouer funksionele koppelvlakke. J2EE- en ASP.Net-programme word gewoonlik meer beskerm teen hierdie aanvalle. As 'n kwesbaarheid van die SQL-inspuiting gevind word – en dit maklik gevind kan word – word die omvang van die potensiële aanvalle slegs beperk deur die vaardigheid en verbeelding van die aanvaller. Dus is die impak van 'n SQL-inspuiting aanval ongetwyfeld groot.
Hierdie aanvalle is ook moontlik, hoofsaaklik as gevolg van onvoldoende insetvalidering. Dit verskil van kode-inspuiting aanvalle deurdat die aanvaller stelselopdragte plaas in plaas van stukke programmeringskode of skrifte. Daarom hoef hacker nie die programmeringstaal waarin die toepassing gebaseer is of die taal wat deur die databasis gebruik word, te ken nie. Maar hulle moet weet wat die bedryfstelsel is wat deur die hosting-bediener gebruik word.
Die ingevoerde stelselopdragte word uitgevoer deur die gasheerbedryfstelsel met die voorregte van die toepassing, wat moontlik kan maak om die inhoud van arbitrêre lêers wat op die bediener woon, bloot te lê, om die gidsstruktuur van 'n bediener te wys, om gebruikerswagwoorde te verander, onder andere.
Hierdie aanvalle kan deur 'n sysadmin voorkom word deur die stelsel se toegangsvlak van die webtoepassings wat op 'n bediener loop, te beperk.
Telkens wanneer 'n toepassing invoer vanaf 'n gebruiker invoeg in die uitset wat dit genereer, sonder om dit te verifieer of te kodeer, gee dit die geleentheid vir 'n aanvaller om kwaadwillige kode na 'n ander eindgebruiker te stuur. XSS-aanvalle gebruik hierdie geleenthede om kwaadwillige skrifte op betroubare webwerwe te spuit, wat uiteindelik aan ander gebruikers van die toepassing gestuur word, wat die slagoffer van die aanvaller word.
Die blaaier van die slagoffers voer die kwaadwillige skrif uit sonder om te weet dat dit nie vertrou moet word nie. Daarom laat die blaaier dit toegang tot sessietokenens, koekies of sensitiewe inligting wat deur die blaaier gestoor word. As dit behoorlik geprogrammeer is, kan die skrifte selfs die inhoud van 'n HTML-lêer herskryf.
XSS-aanvalle kan oor die algemeen in twee verskillende kategorieë verdeel word: gestoor en gereflekteer.
in gestoor XSS-aanvalle, die kwaadwillige skrif lê permanent op die teikenbediener, in 'n boodskapforum, in 'n databasis, in 'n besoekerslogboek, ens. Die slagoffer kry dit wanneer die blaaier die gestoorde inligting versoek. in weerspieël XSS-aanvalle, die kwaadwillige skrif word weerspieël in 'n antwoord wat die insette wat na die bediener gestuur is, insluit. Dit kan byvoorbeeld 'n foutboodskap of 'n soekresultaat wees.
Hierdie soort aanval is moontlik wanneer 'n webtoepassing inligting gebruik wat deur 'n gebruiker verskaf word om 'n XPath-navraag vir XML-data te bou. Die manier waarop hierdie aanval werk, is soortgelyk aan SQL-inspuiting: aanvallers stuur verkeerde inligting na die toepassing om uit te vind hoe die XML-data gestruktureer is, en dan val hulle weer aan om toegang tot die data te kry.
XPath is 'n standaardtaal waarmee u, net soos SQL, die eienskappe wat u wil vind, kan spesifiseer. Om 'n navraag oor XML-data uit te voer, gebruik webtoepassings gebruikerinvoer om 'n patroon te stel waarop die data moet ooreenstem. Deur verkeerde vorms te stuur, kan die patroon verander in 'n operasie wat die aanvaller op die data wil toepas.
Anders as wat met SQL gebeur, is daar in XPath geen verskillende weergawes nie. Dit beteken dat XPath-inspuiting gedoen kan word op enige webtoepassing wat XML-data gebruik, ongeag die implementering. Dit beteken ook dat die aanval geoutomatiseer kan word; daarom, anders as SQL-inspuiting, het dit die potensiaal om afgedank te word teen 'n arbitrêre aantal doelstellings.
Hierdie aanvalmetode kan gebruik word om e-posbedieners en toepassings te gebruik wat IMAP- of SMTP-stellings bou met verkeerd gevalideerde gebruikersinvoer. Soms het IMAP- en SMTP-bedieners nie 'n sterk beskerming teen aanvalle nie, aangesien dit die geval sou wees met die meeste webbedieners, en daarom meer ontginbaar kan wees. Aansoekers kan via 'n e-posbediener ingaan, beperkings kan ontduik soos captchas, 'n beperkte aantal versoeke, ens.
Om 'n SMTP-bediener te benut, benodig aanvallers 'n geldige e-posrekening om boodskappe met ingespuit opdragte te stuur. As die bediener kwesbaar is, sal dit reageer op die aanvallers se versoeke, wat hulle byvoorbeeld toelaat om bedienerbeperkings te ignoreer en sy dienste te gebruik om spam te stuur.
IMAP-inspuiting kan hoofsaaklik op webpos-toepassings gedoen word en die funksionering van die boodskaplees benut. In hierdie gevalle kan die aanval uitgevoer word deur eenvoudig, in die adresbalk van 'n webblaaier, 'n URL met die ingespuit opdragte in te voer.
Die invoeging van karretjie-terugkeer- en lynvoerkarakters – kombinasie bekend as CRLF – in webvorminvoervelde verteenwoordig 'n aanvalmetode genaamd CRLF-inspuiting. Hierdie onsigbare karakters dui aan die einde van 'n reël of die einde van 'n opdrag in baie tradisionele internetprotokolle, soos HTTP, MIME, of NNTP.
Byvoorbeeld, die invoeging van 'n CRLF in 'n HTTP-versoek, gevolg deur 'n sekere HTML-kode, kan aangepaste webbladsye aan die besoekers van 'n webwerf stuur.
Hierdie aanval kan uitgevoer word op kwesbare webtoepassings wat nie die regte filter op die gebruikersinvoer toepas nie. Hierdie kwesbaarheid maak die deur oop vir ander vorme van inspuitaanvalle, soos XSS en kode-inspuiting, en kan ook spruit uit 'n webwerf wat gekaap word.
In bedieners wat baie webwerwe of webtoepassings huisves, word die gasheeropskrif nodig om te bepaal watter van die inwonende webwerwe of webtoepassings – een van hulle wat 'n virtuele gasheer genoem word – 'n inkomende versoek moet verwerk. Die waarde van die koptekst sê vir die bediener aan wie van die virtuele gashere 'n versoek moet versend. As die bediener 'n ongeldige gasheerkop ontvang, stuur dit dit gewoonlik na die eerste virtuele gasheer op die lys. Dit is 'n kwesbaarheid wat aanvallers kan gebruik om arbitrêre gasheeropskrifte na die eerste virtuele gasheer op 'n bediener te stuur.
Manipulasie van die gasheerkop is gewoonlik verwant aan PHP-toepassings, hoewel dit ook met ander webontwikkelingstegnologieë gedoen kan word. Aanvalle op gasheeropskrifte werk as instaatstellers vir ander soorte aanvalle, soos vergiftiging op die web-kas. Die gevolge daarvan kan insluit die uitvoering van sensitiewe operasies deur die aanvallers, byvoorbeeld wagwoordterugstelling.
LDAP is 'n protokol wat ontwerp is om die soeke na hulpbronne (toestelle, lêers, ander gebruikers) in 'n netwerk te vergemaklik. Dit is baie nuttig vir intranette, en as dit gebruik word as deel van 'n enkele aanmeldstelsel, kan dit gebruik word om gebruikersname en wagwoorde te stoor. LDAP-navrae behels die gebruik van spesiale beheerkarakters wat die beheer daarvan beïnvloed. Aanvallers kan die beoogde gedrag van 'n LDAP-navraag potensieel verander as hulle beheerkarakters daarin kan plaas.
Weereens, die wortelprobleem wat LDAP-inspuitingsaanvalle moontlik maak, word verkeerdelik deur die gebruikerinvoer bevestig. As die teks wat 'n gebruiker na 'n program stuur, gebruik word as deel van 'n LDAP-navraag sonder om dit te ontsmet, kan die navraag uiteindelik 'n lys van alle gebruikers ophaal en dit aan 'n aanvaller wys, net deur 'n asterisk (*) aan die regterkant te gebruik plaas binne 'n insetstring.
Voorkoming van inspuitings
Soos ons in hierdie artikel sien, is alle inspuitingsaanvalle gerig op bedieners en toepassings met 'n oop toegang tot enige internetgebruiker. Die verantwoordelikheid om hierdie aanvalle te voorkom, word onder toepassingsontwikkelaars en bedieneradministrateurs versprei.
Toepassingsontwikkelaars moet weet wat die risiko's is wat verband hou met die verkeerde validering van gebruikersinvoere en die beste praktyke moet leer om gebruikers se insette te sanitiseer met die oog op risikovoorkoming. Bedienersadministrateurs moet hul stelsels van tyd tot tyd oudit om kwesbaarhede op te spoor en dit so gou as moontlik reg te stel. Daar is baie opsies om hierdie oudits uit te voer, hetsy op aanvraag of outomaties.