13. maj 2008 - 10:39Der er
4 kommentarer og 1 løsning
Hvordan spærres for SELECT-adgang til SYS-tabeller ?
Jeg har desværre været så uheldig, at min side bliver angrebet med SQL-injection, den såkaldte nihaorr1, der via SYS-tabellerne finder ud af hvilke text-felter, der eksisterer i min database og derefter overskriver data i disse med et js-script.
Jeg er nu blevet rådet til at stoppe dette quick and dirty ved at spærre for SELECT-adgang til filerne Syscolumns og sysobjects.
Spørgsmålet er nu: hvordan gøres dette? Og har det indflydelse på min øvrige applikation (applikationen selecter ikke selv direkte fra sys-tabellerne)?
Jeg er desværre ikke selv web-udvikler, og min webhotel-udbyder har ikke kompetence nok til at svare på disse spørgsmål. Et svar bedes derfor givet på en måde så det er til at forstå for både mig og min webhotel-udbyder, på trods af vores begrænsede viden om SQL permissions.
PS. Jeg er klar over at den bedste løsning naturligvis er at finde og lukke hullet/hullerne i applikationen, der gør SQL-injection mulig, men denne opgave kan tage tid. Dette ønsker jeg iøvrigt også hjælp til, men det er en anden historie.
Det er nok lidt svært når dine muligheder er så begrænsede, men du kan sætte en replace på dine dynamiske sql-strenge som erstatter tekststrenge som 'syscolumns' og 'sysobjects' til noget andet og så vil sql'en fejle når den fyres af, men det gør vel ikke noget.
Et hint til hvorledes du undgår det i fremtiden. Lad alle tekstrenge blive escapet før du sætter dem ind i din sql-streng, så undgår du at der kan sniges noget 1=1 og alt sådan noget ind i dine sql'er.
En Replace af alle dynamiske sql-strenge kræver vel stadig at man lokaliserer alle de steder i applikationen, hvor sql-strenge genereres?
Det smarte ved løsningen med at spærre for SELECT af sys-tabellerne var jo netop at jeg ikke behøvede at finde alle huller i kildekoden. I hvert fald ikke i første omgang - jeg er godt klar over at det vil være det sundeste på længere sigt.
Ja det er altid trist når sådan noget sker. Det som du kan komme lidt længere med er flg.
use [ditdatabasenavn] deny select on sysobjects to [den_webuser_som_du_bruger]
Det er ikke sikkert at ovenstående er noget du selv har rettigheder til at udføre, men jeg kan høre du taler med dit webhotel, så det burde ikke give problemer at få eksekveret.
Mht. om applikationen selv selecter fra sysobjects.... tjaa den er svær at svare på. Det ses jo engang imellem at der oprettes tabeller efter behov, når det så sker så er det typisk med: if exists(select * from sysobjects where name = 'asdads')
Og det selvom Microsoft fraråder at gøre sådan *GG*, hvis det nu alligevel skulle være tilfældet at det sker i netop din applikation så skal du bruge det som anbefales, nemlig:
select * from information_schema.tables
Men ellers vend tilbage, hvis det er tilfældet :-)
Tak for svaret. Det var præcis den syntaks jeg efterspugte: DENY SELECT ON ...
Dette lukker for det aktuelle sql-inject angreb. Desværre lukker den jo ikke for andre, mere sofistikerede og ondsindede angreb, der f.eks kan gøre brug af din select * from information_schema.tables. Men den tid, den "glæde" - i mellemtiden vil jeg udnytte tiden til at finde de huller i applikationen, der giver mulighed for sql injection.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
