Er sikkerheten på norske nettsider for dårlig ?

[adeneo]

Med litt fritidsproblemer i helgen fant jeg det for godt å sjekke litt sikkerhet på tilfeldig utvalgte norske nettsider, og resultatet var egentlig ikke uventet ganske begredelig, derav spørsmålet "er sikkerheten på norske nettsider for dårlig" ?

Litt mer informasjon om hva jeg mener;
Jeg brukte noen timer på å sjekke sikkerheten på de første 100 nettsidene jeg fikk opp på Google.
Google gir meg 10 resultat per side, slik at jeg gikk fort igjennom de første 10 sidene.
Søket var på noe så trivielt som "wp-content" for å få kun nettsider som kjører Wordpress, og ytterligere snevret inn til kun .no domener, samt en ting til, som jeg ikke opplyser om for at andre ikke skal få samme søkeresultater, men det er ikke søkt spesielt etter sårbarheter, kun vanlige WP nettsider.

Jeg er forøvrig ingen hakker (kanskje litt på hobbybasis), men følger med på hvilke plugins det er oppdaget sikkerhetshull i osv. og følger nok kanskje litt bedre med enn "folk flest".

Ved å se på kildekoden, var det 6 nettsider hvor det tok nærmest bare sekunder å finne utdaterte plugins, av disse brukte 2 nettsider WordFence, som beskytter en hel del, og jeg gidder ikke bruke tid på de, men bare går videre til neste side.
De 4 resterende lot meg fritt finne innloggingsinfo for databasen deres rett i nettleseren ved å dytte inn den "rette" URL'en.
2 av de faktisk gjennom eldre versjoner av Revolution Slider, som jeg trodde alle hadde fått med seg ikke var sikker lengre og må oppdateres?

Nå har selvfølgelig ikke jeg gått videre og logget inn i databasen deres, det ville være ulovlig, men med innloggingsinfo til databasen så hadde jeg ikke trengt å knekke hashen av passordet en gang, jeg kunne logget meg direkte inn i databasen og endret hashen for admin kontoen med en hash jeg selv har laget, og tatt kontroll over nettsiden og webhotellet deres i løpet av maks 3-4 minutter.

Nå skal ikke jeg gå så veldig innpå akkurat fremgangsmåter for hacking, det ville ikke være ulovlig å skrive om det, men vi får prøve å unngå å tilrettelegge for at andre gjør noe ulovlig, det var ikke det som var poenget.

PS: Ingen teknikker som kunne skade nettstedene ble brukt, ikke XSS og ikke SQLi med ting som "drop table" eller lignende, kun vanlige URL'er som dersom de er feil utformet har den bieffekten at nettsidene viser hele databasen eller innloggingsinfo til databasen.
Dette er på ingen måte ulovlig, ei heller å knekke hasher og lignende, så fremt man ikke bruker den informasjonen til å logge inn på andres nettsider og ødelegge noe, da vil det være ulovlig, noe jeg selvfølgelig aldri gjør.

4% av Wordpress nettsider funnet på et standard Google søk kan altså hakkes av en amatør i løpet av 3-4 minutter !

Vi har da allerede fått tilgang til 4 nettsider, utelukket 2 på grunn av WordFence som vi ikke gidder å rote med, samt at en av nettsidene pussig nok allerede var hacket og "defaced" med noe greier fra Iran, med Allah Akhbar og fengende persisk musikk, og den har helt sikkert blitt tatt ned av en bot, altså var den dårlig sikret.

Neste skritt var å sjekke etter SQLi (SQL-injection).

Jeg brukte noen minutter på hver av av de resterende 93 nettsidene, og på 22 av de fant jeg nesten umiddelbart querystrings ved å følge med på adressen i nettleseren min og bare trykke rundt i full fart på alle mulige lenker (querystrings er altså når det er et spørsmålstegn i lenken, som "?page_id=3").
På noen av sidene var permalenker slått på, som betyr at det er querystrings lagt til av diverse plugins, mens på andre var permalenker slått av, ikke at det egentlig spiller noen rolle, men permalenker gjør det generelt sett vanskeligere å finne et angrepspunkt for SQLi.

Ved så å prøve noen kjente triks med å provosere frem feilmeldinger ved å putte diverse rare tegn i adressefeltet i nettleseren, hadde 7 av nettsidene PHP/SQL feilmeldinger slått på (for Guds skyld, slå alltid av feilmeldinger).
Jeg har en maskin med Kali (Linux for "sikkerhetstesting", host, host) installert, og prøvde med noen automatiserte verktøy jeg ikke nevner navn på (det ville være for enkelt å følge), og fikk ned hele databasen på alle 7 nettsidene i løpet av noen minutter, med andre ord alle brukerkontoer og passord fra Wordpress, samt alt mulig annet.
Disse verktøyene lager og prøver URL'er med diverse "kommandoer" integrert for å vise databasen, ikke noe annet.
Et godt eksempel er dersom en gyldig lenke er noe sånt som "http://nettside.no?user=3" så prøver man kanskje "http://nettside.no?user=3 AND 1=1", som kan være en injection dersom en nettside mangler totalt sikkerhet.

Nå er passord hashet i Wordpress, men det er som standard kun MD5 hashing kjørt gjennom noe som heter phpass, og det kan enkelt knekkes med Hashcat, John the Ripper eller lignende, som selvfølgelig er inkludert i Kali.

En kjapp test med noen ordlister og seks skjermkort som bråker som en traktor (GPU er raskere enn CPU), og i løpet av 20 minutter var passordet til adminkontoen for 5 av 7 nettsider funnet, som jeg selvfølgelig ikke testet å logge inn med, det ville være ulovlig.
De resterende 2 passordene kunne sikkert også vært funnet ved å bruke litt mer tid, det er som regel ikke noe problem å knekke hashene, har man først fått tak i hashene og brukerkontoene så er sikkerheten allerede brutt.

Ytterligere 7% av norske Wordpress sider kunne altså hakkes i løpet av en halvtime.
Ettersom jeg kun fikk ned databasen fra 7 av 22 nettsider valgte jeg å prøve de resterende 15 i noe som heter Havij, et vanlig Windows program jeg sjelden bruker, og helt fullstendig uventet fikk jeg ned databasen til ytterligere 3 av sidene ved å kun klikke på en knapp (?).
Altså totalt 10 sider, eller 10%, kunne hakkes med SQL injection i løpet av 15-30 minutter.

Inkludert den siden som allerede var hakket av en Iraner med fremragende musikksmak, var det mulig å få admintilgang til rundt 15% av Norske nettsider som kjører Wordpress i løpet av toppen en halvtime per side.

Flere av disse sidene var satt opp av profesjonelle byråer, og en av nettsidene tilhører en større nasjonal forening med en del brukerinformasjon i databasen, og denne siden hadde "nesten" adminpassordet til hele databasen postet på forsiden, og som tok 1 minutt å finne, . Skremmende!

Jeg laget så kjapt et script (vel, det tok et par timer) som kjørte en scan med WPscan og Metasploit på de 85 nettsidene som var igjen.
Da begynner det å bli litt mer avansert, men fortsatt på "script-kiddie" nivået, og bare 5 av nettsidene hadde ingen kjente hull.
Altså totalt var det sikkerhetshull i 95% av nettsidene som ble testet.
Det betyr ikke nødvendigvis at det er enkelt å hakke en slik nettside, dette var kun en scanning etter feil på sikkerheten som potensielt kan utnyttes.
Noen av disse hullene er også ting som XSS eller CSRF som ikke er så veldig interessante ettersom det som regel tar lengre tid og mer kunnskap å utnytte de, samt at det også er hull som kan være tettet av andre plugins, slik som WordFence eller lignende.
En kontrolltest med Arachnid fant alvorlige sikkerhetshull i 42 av de resterende nettsidene.

Jeg ville tippe rundt halvparten av de 85 nettsidene kunne hackes i løpet av et par timer per side, uten at jeg vet sikkert, det er grenser for hvor mye tid jeg har til overs.

Alt kan hackes dersom man bruker nok tid og ressurser på det, men nivået på sikkerheten på Norske nettsider ser generelt ut til å være helt elendig, kun 5 av 100 nettsider så ut til å være sikre mot godt kjente angrep i Metasploit databasen.

Dette er vel egentlig fullstendig uakseptabelt ?
Nå vet ikke jeg hvordan tallene ville vært for nettsider fra andre land, sikkert ikke noe bedre, og det er forståelig at ikke alle kan følge med på alt mulig innen sikkerhet, slik at Olsen i 4B som lager hjemmeside for borettslaget er til dels fritatt, men som nevnt var de fleste av disse norske nettsidene satt opp av profesjonelle norske byråer, og en av sidene jeg fikk tilgang til tilhørte faktisk et norsk web-byrå som reklamerte med billige Wordpress nettsider ?

Dette ble fire ganger lengre enn jeg hadde tenkt til å skrive, men kanskje det kan få mange av de som driver å setter opp slike nettsider til å lære seg et minimum om sikkerhet på nett, eller i det minste installere en av de kjente plugins'ene for sikkerhet.
Bare det å få opp meldingen "Din aktivitet på denne siden har blitt begrenset av WordFence ... slem gutt ... osv" gjør at jeg, og sikkert de fleste andre også, bare går videre til den neste på listen, og derfor virker det mot de aller enkleste angrepene.

TL;DR - 15 av 100 norske Wordpress nettsider kunne enkelt hackes av hvem som helst på under en halvtime, 95% hadde kjente sikkerhetshull.

 

[Dostojevskij]

Gjelder dette bare WP-sider, eller tror du at du kunne hacket andre sider også? Og hvorfor er det egentlig sånn at man i 2015 fortsatt kan sql-injecte sider? Dette er jo enkelt å sikre seg mot.

 

[xdex]

Jeg opplever det samme som @adeneo og det er ikke sjokkerende. Mange setter opp Wordpress sider, og lar det ligge, selv om dem aktivt bruker nettstedet. Mange gidder ikke oppdatere plugins, og ytterst få følger med på hvordan miljøet beveger seg.

Jeg er aktiv bruker av verktøy som søker etter feil, ofte for kunder, men selvfølgelig for egne nettsider også. Det som sjokkerer meg mest, er at folk ofte beholder backup filer på serveren. Jeg vet om minst 2 nettsider som promoteres her på webforumet, som faktisk har en wp-config.txt åpent (.txt fordi det er tatt backup av config filen, ved hjelp av en amatør plugin), og denne er tilgjengelig for alle (ja, jeg har sendt PM, så ikke tenk på det).

Jeg vil si at det største problemet er to ting

1) Bedrifter som ikke tilbyr vedlikeholds-avtaler, eller påstår at dem gjør det, uten at det følges opp i det hele tatt.
2) Brukere av Wordpress har for lite kunnskap, og installerer plugins i hytt å pine, uten noen form for research.

Gjelder dette bare WP-sider, eller tror du at du kunne hacket andre sider også? Og hvorfor er det egentlig sånn at man i 2015 fortsatt kan sql-injecte sider? Dette er jo enkelt å sikre seg mot.

Tull, det er faktisk ikke så "lett" som det du sier her. Flere store nettsider har sikkerhetsproblemer, og det er derfor nettsider som Facebook, Google etc, betaler gode penger for folk som rapporter og kan bevise feil. Ja, det er veldig lett å sikkre seg mot slike ting, dersom dette er ett lite nettsted, med "null" fleksibilitet. Legg til API support, 3-parts systemer og flere servere, så skal du se at ting eskalerer fort.

XSS og CSRF er langt mer "morsomt/spennende" dersom det gjøres riktig. Her kan du virkelig ødelegge systemer, om du kjenner til hvordan ting fungerer. Veldig kjedelig å trykke på en lenke, for å så oppdage at du slettet din egen bruker, uten at noen hadde tilgang.

MD5 er selvfølgelig ett stort problem, men mange eldre nettsider bruker fortsatt dette. Vi vil nok se nettsider gå over på nye systemer etterhvert, sha1, bcrypt osv.

Det største problemet er jo ikke at du besøker ett nettsted, hvor du møter flagg, påstander, og "Hei hei du er hacket". Den største trusselen er det du ikke ser. Hijacking av nettsider, med skjulte lenker er mer og mer populært. På den måten får ett nettsted tusenvis av back-links, uten at du er klar over det selv. Dette blir mer og mer populært, samt hijacking av annonser. Det ser ut som dine egne, men det er det altså ikke, og oppdages kanskje ikke før det har gått noen dager.

Jeg er langt mer bekymret for en skjult agenda, enn at noen finner ut passordet mitt, nettopp fordi man blir utsatt for noe, uten å vite det. Plutselig er du så hardt straffet av Google, at du bare kan glemme å ligge på gode søkeresultater.

 

[Dostojevskij]

Tull

Jeg mente ikke at sikkerhet var lett generelt, men akkurat dette med sql-injection er vel ikke så vanskelig å beskytte seg mot?

 

[xdex]

Jeg mente ikke at sikkerhet var lett generelt, men akkurat dette med sql-injection er vel ikke så vanskelig å beskytte seg mot?

For å svare veldig enkelt, ingenting er vanskelig hvis du vet hvordan. Det største problemet er uansett hvor lett det er å gjennomføre, og hvor lett det er å la noe stå åpent. Absolutt en stor svakhet med PHP, men de fleste rammeverk beskytter seg selv mot dette. Men plugins i Wordpress, kan gjerne stå på vidt gap, fordi utviklere der ute gjør feil, eller glemmer å tette hullet.

Det er faktisk ofte 3-parts systemer som gjøre noe som dette mulig, f.eks. plugins.

 

[Travellingman]

Har på alle mine sider beskyttet innlogging med .htaccess og bruker Wordfence. Oppdaterer alt fortløpende og bruker ikke plugins som er utdaterte. Antar det skulle holde greit for en amatør som meg?

 

[adeneo]

Jeg mente ikke at sikkerhet var lett generelt, men akkurat dette med sql-injection er vel ikke så vanskelig å beskytte seg mot?

Det er både og, å beskytte seg mot de enkleste SQLi angrepene er selvfølgelig egentlig veldig enkelt, samtidig er det veldig fort gjort for utviklere å gjøre en liten feil som åpner opp databasen.

SQL injection er økende, og utgjør snart 80% av alle angrep på nettsider nå.

Det finnes ingen 100% sikker måte å beskytte seg mot alle typer SQL injection, annet enn å ikke bruke en database.
Det er rett og slett for mange mulige "angrepsvektorer" som det heter så fint, og det oppdages stadig kompliserte spørringer som er utformet spesielt for å komme rundt ting som escaping eller prepared statements, og det er sikkert mange typer SQL injection som ikke er kjent enda en gang.

For noen år siden var det mysql_real_escape_string osv. som skulle brukes, og det var vist nok trygt, men selv klassikeren "1=1" kan med litt uflaks gå igjennom

$query = "1 OR 1=1"; // si dette kommer fra $_GET, altså fra adresselinjen i nettleseren

$id = mysql_real_escape_string( $query ); // det er egentlig ingen ugyldige tegn å escape ?
$sql = "SELECT * FROM table WHERE id = $id"; // spørringen kjøres som tiltenkt, alle data listes opp

mysql_query( $sql );

dette ville gitt alle brukere i databasen ettersom "1 OR 1=1" satt inn som bruker ID ville vært "true", og MySQL ville spyttet ut alt, problemet med koden ovenfor er rett og slett at noen har glemt quotes, det burde vært :

$sql = "SELECT * FROM table WHERE id = '$id'";

men si utvikleren har vært flink nok til å huske quotes, og har en spørring lignende dette

$id = $_GET['navn']; // for eksempel Kjell ?

$var = mysql_real_escape_string( $id );

mysql_query("SELECT * FROM table WHERE name = '$var' LIMIT 1");

ser jo greit ut, det er brukt quotes rundt variabelen, og det er til og med satt en limit slik at kun ett resultat returneres, men så setter man inn følgende i adresselinjen

http://url.no?navn=\xbf\x27 OR 1=1 /*

og ender opp med noe tilsvarende dette

$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM table WHERE name = '$var' LIMIT 1");

Her er vi avhengig av at MySQL bruker et av følgende tegnsett, big5, cp932, gb2312, gbk eller sjis, dette vil ikke virke med utf8 tegnsett, men det finnes måter å omgå det på også.

Det vi ender opp med når spørringen evalueres er

"SELECT * FROM table WHERE name ='縗' OR 1=1/*' LIMIT 1";

der har vi plutselig fått lurt inn en enkeltquote som lukker rundt det rare tegnet, så har vi noe som evaluerer til "OR true", som selvfølgelig er sant, og deretter kommenterer vi ut det som egentlig skulle vært den lukkende enkeltquotes, samt hele limit greia, med /* slik at den blir aldri sett av MySQL uansett, og ut kommer alle brukernavn, nok en gang.

Så fort er det gort, det samme gjelder i grunn for prepared statements, altså PDO og lignende, som egentlig er ganske trygt, men det er fort gjort å gjøre en feil, for eksempel hvis noen har fått den gode ideen at de skal bygge spørringer dynamisk eller lignende

$limit = $_GET['limit'];
$navn  = $_GET['navn'];

$sql = "SELECT * FROM table WHERE name = '" . $navn . "' LIMIT " . $limit;

$pdo = new PDO('mysql:host=localhost;dbname=testdb', $user, $password);

$pdo->query($sql);

Koden ovenfor er selvfølgelig helt åpen ettersom data fra $_GET settes direkte inn i spørringen, men mange tror at det er trygt å gjøre det sånn, det er tross alt PDO, som alle sier er trygt ?

Nå er det så ikke ofte man ser så dårlig SQL, men det forekommer likevel stadig at noen har gjort noe lignende og brukt data direkte uten å validere på noe som helst måte, det er jo ofte slik man setter inn variabler i strings i PHP, så hvorfor ikke gjøre det i PDO også?

Det virker nok mye lettere for mange å gjøre det som ovenfor, i stedet for å rote med alle disse spørsmålstegnene, eller enda verre kolon og labels og slikt.
Vet man ingenting om sikkerhet så fremstår det som helt greit å gjøre det på den måten, og selv oppegående utviklere forstår ikke alltid hva spørsmåltegnene er til, og tror at så lenge det er PDO, så er det uansett sikkert, noe det selvfølgelig ikke er.

Det burde selvfølgelig vært skrevet mer lignende

$limit = $_GET['limit'];
$navn  = $_GET['navn'];

$sql = "SELECT * FROM table WHERE name = ? LIMIT ?";

$pdo = new PDO('mysql:host=localhost;dbname=testdb', $user, $password);

$stmt = $pdo->prepare( $sql );
$stmt->execute(array($navn, $limit));

Det er nesten alltid en utvikler som har gjort en eller annen feil når en nettside er åpen for SQLi, men det er samtidig så fort gjort å gjøre slike feil, at alle gjør det en eller annen gang, og som xdex nevner så har også verdens største nettsider sikkerhetsproblemer, og de har alle vært offer for SQL injection også, og kommer sannsynligvis til å bli det i fremtiden også.

 

[Dostojevskij]

Det finnes ingen 100% sikker måte å beskytte seg mot alle typer SQL injection, annet enn å ikke bruke en database.
Det er rett og slett for mange mulige "angrepsvektorer" som det heter så fint, og det oppdages stadig kompliserte spørringer som er utformet spesielt for å komme rundt ting som escaping eller prepared statements, og det er sikkert mange typer SQL injection som ikke er kjent enda en gang.

Selv hvis man bruker et PHP-rammeverk - som xdex nevner - kan det altså likevel være behov for tiltak for å unngå SQL injection?

 

[TorsteinO]

Det er helt klart et kjempeproblem at folk glemmer å oppdatere nettsidene sine - eller - som selv mange litt større mediebyråer osv - egentlig ikke har peil utover at de har oppdaget hvor enkelt det er å sette opp en side med et theme fra themeforest e.l.

F.ex. var det en jeg snakket med som skulle ha litt hjelp til å fikse opp webshopen sin, og jeg spurte om hun også ville ha en driftsavtale, men nei, det ville hun ikke ha, hun jobbet i et mediebyrå, så hun visste hvor lite jobb det var med nettsider etter at de var satt opp. Ok, greit det, noen er jo flinke til å passe på. Så logger jeg inn... og oppdager at INGENTING har blitt oppdatert siden nettsidene opprinnelig ble satt opp for over et år siden. Ja, hvis man ikke gjør noen oppdateringer i det hele tatt er det VELDIG lite jobb - helt til man blir hacka ihvertfall...

Av nysgjerrighet kikket jeg så over alle nettsidene dette mediebyrået skrøt av at de hadde laget på facebook, og uten unntak var alle themes fra themeforest, vanligvis var theme-navnet endret, men ellers så de så standard ut at alt sannsynligvis bare var valgmuligheter i theme options e.l. Jeg visste også om en annen som hadde skullet få laget side av det samme byrået, der hadde avtalen blitt inngått nesten et halvt år tidligere, og det viste seg at de sleit skikkelig, rett og slett fordi han hadde hatt med seg et design som han ville ha laget, i stedet for at de bare kunne kjøpe et theme var de plutselig nødt til å KODE. Da stod de tydeligvis helt fast, ingenting funka og sidene så helt feil ut, etter nesten et halvt år. Det var heller ikke noe vriene greier han skulle ha, det var veldig veldig standard og rett fram.

 

[adeneo]

Selv hvis man bruker et PHP-rammeverk - som xdex nevner - kan det altså likevel være behov for tiltak for å unngå SQL injection?

Rammeverk er vanligvis noe sikrere fordi de oppdateres regelmessig, og sikkerhetshull lukkes i hvert fall når de oppdages, men det er bare noen måneder siden SQL injection ble oppdaget i FuelPHP, CakePHP, CodeIgniter og Laravel.
Alle hadde det samme problemet som relativt raskt ble oppdaget av Peter Bex etter litt testing, mer her -> http://java.dzone.com/articles/how-your-frameworks-may-be

Disse hullene er nå lukket av rammeverkene, men nye slike sikkerhetsproblemer oppdages hele tiden, for bare et par dager siden var det en plugin som heter "MainWP Child" som vist nok gir full admintilgang uten autentifikasjon, og det er estimert at denne plugin'en er installert på rundt 90 000 Wordpress sider.

Det er helt klart et kjempeproblem at folk glemmer å oppdatere nettsidene sine ....

Et problem jeg oppdaget helt tilfeldig ved noen søk på Google, er at mange utviklere legger Wordpress i en midlertidig mappe, ofte "/~temp", "/tmp" eller noe slikt på webhotellet når de utvikler og setter opp nettsiden, databasen og themet, mens de har en annen side tilgjengelig på rot, for eksempel den gamle nettsiden eller "kommer snart" eller noe sånt.

Når de så er ferdig med utviklingen kopierer de alle Wordpress filene over til rot, og begynner å bruke nettsiden.
De oppdaterer og tror alt er i orden, men har helt glemt at det ligger en gammel installasjon på ~temp som ikke er oppdatert.

Jeg har funnet flere titalls slike på webhotell hos Proisp og domeneshop, hvor den gamle installasjonen i den midlertidige mappen er helt glemt, og ikke oppdatert, og hvor det tar bare minutter å hacke den installasjonen selv om nettsiden deres som ligger på rot faktisk er helt oppdatert.

De har rett og slett ikke slettet den gamle installasjonen, enten av frykt for å ødelegge noe, at de har glemt det, eller at de tenkte det var kjekt med en "backup" ?

Det sier seg selv at kommer man inn på den gamle "utviklerversjonen" som admin så har man også tilgang til den samme databasen som den "nye" installasjonen bruker, samt at man gjennom PHP kan utføre kommandoer på det underliggende operativsystemet, sette opp en SSH konto eller lignende, og da hjelper det lite om man har vært flink til å oppdatere "hovedinstallasjonen" når det ligger en egen Wordpress installasjon i en undermappe som er helt åpen.

Det samme gjelder for VPS'er, har man en Wordpress installasjon som er sårbar, er det trivielt å få tilgang til alle de andre som måtte ligge på samme VPS dersom man kommer inn som admin på en av nettsidene.

 

[adeneo]

Har på alle mine sider beskyttet innlogging med .htaccess og bruker Wordfence.

Wordfence er nok ikke veldig sikkert! Dersom det er en eller annen plugin med en feil eller to, så vil man sannsynligvis kunne utnytte det uansett, men plugins som Wordfence oppdateres jo etterhvert med blokkeringer for veldig kjente sikkerhetshull, og bare det å komme til en slik blokkering har en forebyggende effekt.

Med unntak av noen få ullhuer i Iran som fremdeles laster opp tåpelig musikk og merkelige bilder som ingen vet hva er når de får kontroll over en server, så er de fleste som bruker bots eller manuelt søker etter svake nettsider ikke interessert i å ta ned nettsiden, men å ta kontroll over serveren og bruke denne til noe.
For eksempel utsending av spam, proxy for ulovligheter, eller som del av et botnet er populært, og da vil man forsøke å gjøre dette uten at eieren merker noe, og derfor la nettsider og annet stå urørt.

Uansett hva det måtte være, så er det antall som teller, og det er et helt hav av dårlig sikrede nettsider å ta av, også i Norge som jeg skrev i det første innlegget ser det ut som minst 10-15% av nettsider med Wordpress kan taes over i løpet av minutter, og det er nesten rart ikke flere er hacket.

Nå kan det jo være at mange av de faktisk er hacket, som nevnt vil de fleste "seriøse" hackere enten bare la siden være i fred, og hacker kun for å se om de kommer inn, eller så har de lagt inn en bakdør til senere, eller så har de tatt kontroll over serveren uten at det er umiddelbart synlig fra utsiden.

Men, møter man noe sånt som dette (wordfence sikkerhetsmelding) :

http://enovate.no/wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php

så er det ikke verdt tiden å begynne å utforske veier rundt slike sikkerhetsplugin, det er mye enklere å bare gå videre til neste nettside på listen, og derfor er de forebyggende selv om de ikke er helt sikre.

 

[xdex]

Selv hvis man bruker et PHP-rammeverk - som xdex nevner - kan det altså likevel være behov for tiltak for å unngå SQL injection?

Selvfølgelig, se f.eks. på codeigniter, det var helt elendig i en lengre periode, spesielt med tanke på at både CSRF og XSS sikkerheten faktisk var ødelagt i forrige versjon (vet ikke hvordan dette ser ut i dag). Mange i dag bruker fortsatt udaterte rammeverk som utgjør en risiko.

Du kan også se på rammeverk som Laravel, som tidvis kommer med oppdateringer. Sier ikke at alle oppdateringer gjelder sikkerhet, men det er en grunn til at det kommer oppdateringer, ofte fordi det KAN være en trussel.

Syntes forøvrig også at det er viktig å nevne folket som bare tar i bruk andres kode på div nett fora osv. Det er alt for mange i dag, som bare kopierer en kode-snutt, ser at det fungerer, og vips, så er alle fornøyde. Det blir som @adeneo sa, veldig lett og overse små ting som real_escape. Hvis du ikke kan PHP, og lever at å kopiere andres verk, fordi du ikke gidder å lese, eller vil forstå.. kan du bare vente på tidenes smell. Det blir som å lære fra youtube videoer, det innebærer ofte en stor risiko å lære fra en 13åring som nettopp har funnet ut hvordan man lager ett login system. Tips: kjøp en bok, eller betal for skikkelig video/opplæring.

CSRF blir ofte missbrukt, og ble ofte missbrukt på "mafia" spill, slik som vi kjente det i 2003-2006. Da var det om å gjøre og poste en link på forumet, og få flest mulig medlemmer til å klikke på lenken, og deretter se at alle pengene var borte, og overført til en annen person. Dette ser jeg blir ett større problem en sqli injections, fordi folk rett og slett ikke vet hva det er, eller forstår hvordan det fungerer.

Ta en titt på nettsider i dag, og se hvor mange forms som ikke har en hidden field, du vil bli overrasket.

http://en.wikipedia.org/wiki/Cross-site_request_forgery

 

[Dostojevskij]

Du kan også se på rammeverk som Laravel, som tidvis kommer med oppdateringer. Sier ikke at alle oppdateringer gjelder sikkerhet, men det er en grunn til at det kommer oppdateringer, ofte fordi det KAN være en trussel.

Men er dette noe jeg kan gjøre noe med? Så lenge jeg ikke er noen sikkerhetsekspert selv må jeg vel bare anta at Laravel-utviklerne er flinkere til å tette disse sikkerhetshullene enn jeg er? Så da blir spørsmålet - er det så mye mer jeg kan gjøre, annet enn skrive gyldig Laravel-kode og sørge for å ha de siste oppdateringene?

(Med tanke på sql injection altså)

 

[adeneo]

 

[xdex]

Men er dette noe jeg kan gjøre noe med? Så lenge jeg ikke er noen sikkerhetsekspert selv må jeg vel bare anta at Laravel-utviklerne er flinkere til å tette disse sikkerhetshullene enn jeg er? Så da blir spørsmålet - er det så mye mer jeg kan gjøre, annet enn skrive gyldig Laravel-kode og sørge for å ha de siste oppdateringene?

(Med tanke på sql injection altså)

Du kan selvfølgelig gjøre mye, følg med på miljøet, vær aktiv på forum, github, følg dem på twitter etc. Så lenge du følger med på hva som skjer, er du langt mer forberedte, en dersom du ikke gjør det.