mboost-dp1
sxc.hu - simonok
Det gælder bl.a. Odder kommune hvor et meget stort antal sider, som er hostet samme sted, alle eksponerer kommunens borgere samt andre besøgende for det uønskede script der flytter trafikken til en drive-by side som udnytter sårbarheder i populære tredjepartsprogrammer.Odder kommune's hjemmeside har også været yderest modtageligt for SQL injections.
F.eks.
';shutdown()--kan jo være meget morsomt... just sayin'
Når en hacker bruger en SQL-injektion indsætter han en skadelig kode i webadressen, som afvikles af brugeren, som herefter bliver offer for angrebet.At nogen skriver sådan noget vås er lidt pineligt. Men at så mange kopierer den sætning uden at prøve på at forstå den er da endnu mere pineligt.
Jeg skrev en email til JP tidligere i dag fordi de havde det samme vås stående på deres hjemmeside.
Er der nogen som ved hvor man finder en beskrivelse som er skrevet af nogen som faktisk forstår det de selv skriver?
ummm, mon ikke det er et generisk script, der blindly attacker med at injecte html kode overalt?
Så snart noget data fra databasen så vises et sted det ikke er saniteret så blive folk redirected til en drive by download.
Så snart noget data fra databasen så vises et sted det ikke er saniteret så blive folk redirected til en drive by download.
kasperd (7) skrev:
Er der nogen som ved hvor man finder en beskrivelse som er skrevet af nogen som faktisk forstår det de selv skriver?
Jeg kan skrive en til dig:
(Non-persistent) Reflective XSS:
Et reflektivt XSS angreb er når en hjemmeside ikke saniterer input, som derefter udskrives på siden, fra klienten. Når en person så bliver videreført til siden der indeholder det evt. ondsindede input, vil det blive afviklet i brugerens browser.
SQL-injection:
Et SQL-injektion angreb sker når et offentlig parameter på en hjemmeside, der behandles in/direkte af den underliggende database, ikke santiterer input. Det kan fører til at en hacker kan kommunikere direkte med databasen med samme privilegier som hjemmesiden.
Der er mange der tror at der kun er én type XSS angreb.
haha, jeg tror kasperd ved hvad de to termer dækker over- han bticher bare over det ikke er tydeligt hvad de siger.
Nogle gange er det tilfældet. Andre gange er det fordi input ikke escapes korrekt før det bruges i et html dokument.Volatile (9) skrev:XSS angreb er når en hjemmeside ikke saniterer input
Hvis problemet er manglende escaping, og man prøver at udbedre problemet med input sanitation, så resulterer det i et system hvor funktionaliteten er defekt.
Jeg har set webforums hvor man ikke kan diskutere SQL injektion, fordi de i stedet for at escape tekst på den rigtige måde prøver at undgå SQL injektion ved at filtrere på alle SQL nøgleord.
Hvis du har et system hvor du kan lave injektion med et fuldstændigt gyldigt input, så er det fordi der mangler escaping. Hvis man tilføjede den escaping ville problemet være løst. Hvis man i stedet for escaping prøver at validere sit input, så går det galt fordi input allerede var gyldigt.
Først havde du et system hvor nogle gyldige input ikke blev håndteret korrekt. Du lavede en rettelse, som måske nok lukkede sikkerhedshullet, men det resulterede i at der var endnu flere gyldige input der ikke blev håndteret korrekt. I den henseende er det ret ligegyldigt om injektion er med SQL, html eller noget helt tredje.
Hvis du har et felt der f.eks. kun må indeholde tal, så giver det mening at validere input. Hvis du har et felt der indeholder generel tekst (f.eks. et indlæg på et forum), så er alle tegn gyldige i input. De skal bare escapes korrekt til den kontekst de skal anvendes i.
Hvis vi tager webforum eksemplet igen, så kan man vælge mellem to forskellige metoder. Enten tillader man kun ren tekst, og så skal der ingen validering laves, kun escaping. Eller man kan vælge at tillade html, så skal der ingen escaping laves, kun validering. Og validering i det tilfælde går ud på at sikre sig at tags er balanceret, der anvendes kun acceptable tags. Og det skal checkes at html entities i indholdet er korrekt formateret.
Jeg ved godt hvad XSS, XSRF, SQL injektion osv. betyder.Mamad (moveax1ret) (10) skrev:jeg tror kasperd ved hvad de to termer dækker over
Jeg ved ikke hvad nyheden er, jeg er ikke engang klar over om der en nyhed. For det jeg indtil videre har læst nyheden skulle være giver ingen mening.Mamad (moveax1ret) (10) skrev:han bticher bare over det ikke er tydeligt hvad de siger.
Så hvis der er nogen som ved hvad nyheden er og har forstået det, kan de så forklare det for os som indtil videre kun har set kilder som snakker om SQL injektion og tydeligvis ikke ved hvad det vil sige.
I Odder's tilfælde er det SQL injection det drejer sig. Hackerne har dog ikke haft held med deres forehavende.
Prøv at google [dfrgcc site:oddernettet.dk], og kig så på cached resultat. HTML tags er escapede, så det virkede ikke efter hensigten.
De eneste som har lidt skade i dette tilfælde er odder kommune, fordi hackerne har fået ændret nogle tekster.
Prøv at google [dfrgcc site:oddernettet.dk], og kig så på cached resultat. HTML tags er escapede, så det virkede ikke efter hensigten.
De eneste som har lidt skade i dette tilfælde er odder kommune, fordi hackerne har fået ændret nogle tekster.
kasperd (11) skrev:Nogle gange er det tilfældet. Andre gange er det fordi input ikke escapes korrekt før det bruges i et html dokument.
At escape et input er sådan set det samme som at saniterer et input.
Når man siger man saniterer et input, så betyder det jo ikke at man anvender "én-ud-af-mange" løsninger på inputtet. Det betyder bare man filtrer inputtet.
Om man så escaper, indkoder, fjerner, etc. elementer af inputtet, er det stadig en sanitering af inputtet, ved at man "renser" det.
EDIT:
kasper, læs min signatur.
Det lyder som om det der er sket er følgende:TorbenK (13) skrev:Prøv at google [dfrgcc site:oddernettet.dk], og kig så på cached resultat. HTML tags er escapede, så det virkede ikke efter hensigten.
1. Nogen har udført et SQL injektion angreb for at modificere nogle tekster i en database.
2. De tekster der blev sat ind i databasen er et forsøg på at injekte script tags i html koden.
3. Hvis det lykkes vil brugerens browser forsøge at afvikle scriptet fra dfrgcc.com
Det vil sige at for at lykkes skal der altså være to injektion huller i samme site. I eksemplet du gav var det kun den første injektion der virkede, den anden fejlede og resulterer blot i et mærkeligt udseende på siderne.
Men udover at oddernettet.dk kun havde det ene af de to nødvendige huller for at gennemføre angrebet, så ville det alligevel være fejlet fordi webserveren som scriptet ligger på er nede.
Jeg ved altså ikke hvad scriptet gør.
Nyheden på JP påstod at klientmaskinerne blev del af et botnet når man udførte et SQL injektion angreb imod dem.
Det kan være at dette stykke javascript er et forsøg på at gøre computeren til en del af et botnet. Vil det så sige at de har udnyttet endnu et sikkerhedshul til at kompromittere computerne gennem javascript? Eller er der tale om en bot skrevet i javascript?
Det er ikke helt utænkeligt at man har lavet et stykke javascript som forsøger at lave SQL injektion angreb. Men kan det lade sig gøre at lave javascript kode som selv leder efter potentielle steder at lave SQL injektion? Jeg ville umiddelbart ikke have troet at javascript kunne få adgang til de nødvendige data til at starte på.
Hvis der er en central server, som skulle have fortalt hver eneste bot præcist hvilke URLer de skulle tilgå, hvad har de så haft ud af at have et botnet og ikke blot udføre angrebene fra maskiner de havde fuld kontrol over?
Ffs... Parameters! :P
ORM systemer.. :P
Btw. Tror ikke det er forkert at der er brugt sql injections. Men det er nok *også* et xss angreb. Xss'en er nok kørt i forlængelse af sqli'en. :P
Det er til gengæld forkert at sql injection medfører hacks på klienterne / brugerne :P
ORM systemer.. :P
Btw. Tror ikke det er forkert at der er brugt sql injections. Men det er nok *også* et xss angreb. Xss'en er nok kørt i forlængelse af sqli'en. :P
Det er til gengæld forkert at sql injection medfører hacks på klienterne / brugerne :P
kasperd (16) skrev:
Nyheden på JP påstod at klientmaskinerne blev del af et botnet når man udførte et SQL injektion angreb imod dem.
Det kan være at dette stykke javascript er et forsøg på at gøre computeren til en del af et botnet. Vil det så sige at de har udnyttet endnu et sikkerhedshul til at kompromittere computerne gennem javascript? Eller er der tale om en bot skrevet i javascript?
Vil umiddelbart tro at de undbyttede den største bug i computerens historie: end useren.
Hvis de nu replacer samtlige links på siden med et link til en download side med en "browser.exe" el.lign. :P
kasperd (14) skrev:Jeg tænkte ikke specifikt på newz.dk da jeg trak det eksempel frem. Er der forresten nogen som ved om der bliver arbejdet på at lukke XSRF hullerne i newz.dk?
Det var nu en humoristisk henvisning, men jeg kan informere, at SCA ikke har udtalt sig om hullerne.
#13 passer ikke, hvis du også ser min tidligere post, så efter jeg gik ind på odder kommune, stod den og kørte lidt, og endte så med at forsøge at auto printe en pdf ... så jo den laver balade.. du kører måske blot en browser, hvor den fik lov at lave balade uden at du så noget mærkeligt ?
Jeg har "kendt" til en.. Lad os kalde det en bekendt der fortæller at en hjemmeside fra et college havde en skjult admin side hvor der blot skulle indtastes et kodeord. Men fordi man også kunne indtaste hvad som helst og tilføje et SQL injection af den klassiske a=a så spørger html koden egentligt om at der bliver logget ind HVIS passwordet er korrekt, eller at a er lig med a (man kunne også bruge 1=1)
Og da det jo altid er korrekt så ryger man automatisk på admin kontoen..
Det er en del år siden så jeg er sikker på de har fået det lukket.
Det er klassisk SQL injection
Og da det jo altid er korrekt så ryger man automatisk på admin kontoen..
Det er en del år siden så jeg er sikker på de har fået det lukket.
Det er klassisk SQL injection
#21 Det tror jeg nu stadig det gør. Den side du har fundet er sikkert en print venlig version og den er der da ikke noget underligt ved.
På Odder.dk står der 'print' i nederste højre hjørne og trykker du på den bliver onload="javascript:print();" tilføjet body tagget og den forsøger at printe siden ud.
På Odder.dk står der 'print' i nederste højre hjørne og trykker du på den bliver onload="javascript:print();" tilføjet body tagget og den forsøger at printe siden ud.
Nope. mysql.com blev "manuelt" hacket og adgang til siden blev solgt for $3,000 (kilde).webwarp (22) skrev:#19 nu røg mysql.com i hvert fald med i bølgen, så nu er der pænt mange i hvert fald :=)
Sådan som jeg læser det, så er det da ikke CSIS der har skrevet forkert? Det er en masse nyhedssider som intet ved om IT sikkerhed og derfor failer til at omformulere noget tekst.
Det burde virke, hvis der ikke er brug for nogen af de specialtegn i inputtet. Men der kan være situationer hvor de specialtegn der kunne gøre skade er fuldt ud gyldige i inputtet, og så er du nødt til at gøre noget andet for at sitet fungerer korrekt.qw_freak (26) skrev:Så skal lige høre, er det nok at sørge for at "rense" alle inputmuligheder for specialtegn?
Og hvilke tegn der er gyldige er afhængig af hvad feltet anvendes til. F.eks. har jeg set flere eksempler på felter der burde være tal, men hvor der ingen validering laves på inputtet.
Man kunne have checket at feltet kun indeholdt tegnene fra 0-9 og intet andet, og så ville man være på den sikre side. Man bliver så nødt til at overveje om man vil tillade decimaltal og negative tal, hvis man vil det bliver det lidt mere besværligt at checke. Man bør også overveje hvad der sker hvis input starter med 0, da det i nogle tilfælde vil resultere i en anden fortolkning af tallet.
Hvis man tillader indtastning af bogstaver i et felt der burde have været et tal, og som man indsætter direkte i et SQL query, så kan der ske utilsigtede ting.
Man kunne indtaste navnet på et felt i en tabel i stedet for et tal. Så vil der blive sammenlignet med et felt i stedet for en konstant.
F.eks. har jeg engang set et site hvor man kunne søge efter hardware som var til salg, og man kunne indtaste en maksimumspris. Men der var ingen check på at den indtastede pris var et tal. Man kunne f.eks. søge på harddiske og i stedet for en maksimum pris indtaste navnet på det felt der indeholdt diskens størrelse. Så fik man alle de diske der kostede mindre end 1kr pr. GB.
Det er et ret uskyldigt eksempel. Ikke skadeligt og enormt brugbart, men dog trods alt en SQL injektion som gjorde det muligt at bruge formularen til noget den ikke var designet til.
Der kunne være andre tilfælde hvor det gav lidt større problemer. Tag f.eks. en situation hvor databasen indeholder nogle nummererede artikler. En URL parameter indeholder så nummeret på den artikel brugeren vil se. Da parameteren sammenlignes med tabellens primære nøgle vil der højst returneres en række.
Men hvis man i det tilfælde indtastede navnet på det felt i tabellen, så ville det resultere i et query der returnerede alle rækker i tabellen. Dette kunne potentielt udnyttes til et DoS angreb.
Med SQL er der dog en mulighed for at overlade det besværlige arbejde til et lavere lag (som bruges af mange og formodentligt er bedre testet). Det foregår ved at sætte nogle placeholders i det query man konstruerer. Man sætter ikke selv sine parametre ind, men giver dem i stedet som separate argumenter til en funktion, som så konstruerer den endelige query string.
Hvis en URL parameter bruges til at konstruere et SQL query, så er der potentielt mulighed for SQL injektion. Om du modtager parameteren gennem URL parameter eller et felt i en form er ikke så afgørende. Mange sprog på serversiden vil som udgangspunkt være ligeglade hvordan parameteren blev modtaget og give dig værdien uanset om den blev modtaget på den ene eller den anden måde.qw_freak (26) skrev:Og, er der en mulighed også for at lave en SQL injection via URL'en..?
Og når du er ved at beskytte dig imod SQL injektion kan du også være ligeglad. Det er lige nemt for en angriber at give dig en konstrueret værdi på den ene og på den anden måde.
Hvis du er ved at beskytte dig imod XSRF angreb, så gør det en lille forskel om en værdi blev modtaget på den ene eller anden måde. Men den meste effektive måde at beskytte sig imod XSRF angreb er dog ved at tilføje et skjult felt til formen med en hemmelig værdi. Hvis man konstruerer den hemmelige værdi på den rigtige måde, og checker den før man bruger nogen af de andre parametre, så kan man være ligeglad med om de blev modtaget på den ene eller anden måde.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund