De manier waarop u uw website beveiligd tegen hackers is afhankelijk van uw eigen kennis. Bent u bijvoorbeeld een programmeur of een eindgebruiker? De meeste eindgebruikers hebben te weinig kennis van de broncode om hier maatregelen te treffen tegen hackers. Als u een eindgebruiker bent, wilt u er zeker van zijn dat uw website is beveiligd tegen hackers, zodat zij geen ongeoorloofde toegang krijgen tot uw website. Uw klantgegevens moeten achter slot en grendel blijven. SiteSafe kan u hiermee van dienst zijn. Met een Security Audit zoeken wij uit welke risico’s er op uw website bevinden. Met ons rapport kunt u uw website beveiligen tegen hackers.

Als programmeur kan het zijn dat uw kennis niet meer up-to-date is. De belangrijkste aandachtspunten kunt u straks vinden in een nieuwe blog.

SiteSafe denkt “out-of-the-box” en helpt mee met het beschermen van uw servers en klanten. Laat de standaard beveiliging even voor wat het is, en kijk eens met ons mee. Chris Horeweg heeft bij een aantal  hostingbedrijven meegeholpen aan het verbeteren van de beveiliging. Wilt u een vrijblijvende offerte om te zien of uw hostingbedrijf een veilige omgeving biedt voor uw klanten? Neem dan contact op via https://www.sitesafe.nl/

Een flink aantal Nederlandse particulieren en bedrijven hebben tegenwoordig een website. Een website met creaties, informatie over hun hobby of gewoon een blog met van alles en nog wat. Sommige hebben er ook een forum op staan, waar mensen berichten kunnen plaatsen en met elkaar kunnen communiceren.

Wij blijven echter Nederlanders, en betalen het liefste zo min mogelijk. Toch wel een van de redenen waarom er zo afgrijselijk veel “budgethosters” zijn, die de webhostingmarkt overspoelen door zo goedkoop mogelijk webhosting aan te bieden. Shared webhosting, en dan met name budgethosting, kent een flink aantal nadelen. Die nadelen worden natuurlijk niet vermeld op hun website

Shared = Gedeeld en dus betekend het dat je alles deelt. Krijgen een aantal andere websites op de server bezoekers? Grote kans dat jouw website niet bereikbaar is. Maar niet alleen de verbinding is gedeeld, ook de hardware en de software zijn gedeeld.

Bij de meeste webhosters is het mogelijk om gebruik te maken van PHP, MySQL en soms is er ook software aanwezig die pakketten automatisch kan installeren. De webhoster zet eenmalig een webserver neer, installeert alles en is dan klaar. Om de webserver te beveiligen, zet hij er een firewall op, zet een maillimiet neer, en met een klein beetje geluk past hij de instellingen voor PHP aan. Door onkunde of onwetendheid echter, vergeet de webhoster dat er meerdere wegen naar Rome (of Root in dit geval?) leiden..

In een hoop gevallen is het mogelijk om een speciaal bestand uit te lezen, waarin alle gebruikersnamen staan vermeld. Soms staan daar zelfs meer dan 100 in. Door uit te zoeken welke domeinen er op die webserver staan, is het mogelijk om de bestanden van andere gebruikers uit te lezen. Daardoor is het mogelijk, om de website te hacken.

Dit is al een aantal keer gebeurt. Wanneer worden webhosters wakker en gaan ze hier wat aan doen?

SiteSafe daagt webhosters uit om ons als externe partij in te huren op basis van No Cure, No Pay. Bent u er zeker van dat wij niet binnen komen? Laat het zien. Als het ons niet lukt, betaald u niets. Lukt het ons wel, vragen wij een onkostenvergoeding. Uiteraard werken we vertrouwelijk, is het werken met een contract geen probleem en hebben wij een geldig KvK-nummer. Neem even contact met ons op!

Op een van de fora kwam ik een linkje tegen naar File Thingie, een systeem waarmee je online je bestanden kunt beheren. Erg handig, en redelijk veilig. In het verleden is dat anders geweest. Omdat ik toch wel erg nieuwschierig was, ben ik er even mee wezen stoeien. En wat bleek, het lukte mij om een PHP Shell te uploaden! Ik uploadde een bestand met een extensie die in de whitelist stond (.txt). PHP stond in de blacklist. Na wat spelen, kwam ik erachter dat als je een HTML NULL-byte als extensie doet, en daarna een whitelist extensie, het systeem geheel de kluts kwijt is!

Ip-Adressen en de naam van de website zijn weggehaald

Exploit zoals deze zal worden geplaatst op andere websites:
file_thingie_256_exploit.txt

Veel mensen gaan er dus vanuit dat zodra een website een https verbinding heeft, de website ook echt veilig is. Het tegendeel is echter waar. Als de website een beveiligingslek heeft, kan deze alsnog worden uitgebuit. XSS-injecties zijn nog steeds mogelijk, en men komt er pas later achter dat de verbinding niet volledig veilig is. Ook wanneer er een SQL-injectie wordt gevonden, is het nog steeds mogelijk om data te stelen.

Bent u de eigenaar van een website? Maakt u gebruik van een veilige verbinding? Zorg er dan voor dat uw website zelf ook veilig is! SiteSafe kan u daarbij helpen. Lees verder op www.sitesafe.nl!

Webwereld plaatste vorig jaar een artikel waarin staat dat de meeste XSS lekken vaak ongevaarlijk zijn. Het is een interview met Eddy Willems, beveiligingsexpert bij Kaspersky. Hij zegt:

“De ernst van het lek wordt soms uit zijn verband wordt gerukt”, zegt Willems. Volgens hem is de mogelijkheid voor het uitvoeren van een xss-aanval nog niet wil zeggen dat er sprake is van een heel groot gevaar. “Dat is compleet misplaatst.” Volgens Willems toont de mogelijkheid wel aan dat er “een gaatje” is. “Maar dat gaatje is niet altijd de doorgang tot de grote database of tot het misbruiken van bepaalde gegevens die op de site staan. Soms denk ik: ocharm jongens, waar maken we ons hier eigenlijk druk over?”

Sinds januari 2010 hebben wij op zo’n 100 websites XSS-injecties gevonden. De reactie van Willems is dan ook onzin in onze ogen. Vooral de laatste zin vinden wij zeer misleidend.

Het hele doel van een XSS-injectie is het misleiden van een gebruiker. Een simpel voorbeeld:

Bedrijf Water heeft een website. Binnen de website zit een administratie-paneel, waarin medewerkers van het bedrijf orders kunnen plaatsen. Dit zit in een afgesloten gedeelte, om hierop te komen moet iemand zijn ingelogd. Op de website van het bedrijf staat ook informatie voor klanten/bezoekers. Om het bezoekers makkelijk te maken heeft het bedrijf ervoor gekozen om een zoekmachine in te bouwen, zodat bezoekers snel iets op kunnen zoeken.
Binnen deze zoekmachine zit de mogelijkheid tot een XSS-injectie. Hacker Phate heeft de mogelijkheid tot deze XSS-injectie gevonden en heeft een e-mail adres te pakken van een van de medewerkers van het bedrijf. Hij stuurt de medewerker een mail met daarin een URL, en met de vraag of de medewerker hier even naar kan kijken. Omdat de URL precies eruit ziet als hun eigen domein, klikt ze hier op. Er wordt gevraagd om in te loggen. De medewerker kijkt naar de URL en ziet hun eigen domein erin staan. De medewerker vertrouwd dit, en logt in met zijn gegevens. De hacker krijgt 5 seconden later een e-mail, met daarin de zojuist ingevulde gegevens. De medewerker krijgt de melding dat het inloggen is mislukt, en of hij nog een keer wilt inloggen. Hij wordt doorgestuurd naar het eigenlijke systeem, logt in, en vergeet het hele voorval. De hacker kan nu ook inloggen, en download alle klant-gegevens van het bedrijf. Vervolgens chanteert hij het bedrijf, en moet het bedrijf hem een paar ton betalen, voordat de gegevens worden verkocht op de zwarte markt….

In de praktijk komt bovenstaande situatie niet dagelijks voor. Toch kan het voorkomen, al dan niet in een kleinere vorm. Laatst kwam er een brief naar buiten van het Erasmus MC, waarin staat dat 10% van de werknemers (een kleine 1450 man) in een phishing mail was getrapt. Wat als de mail dusdanig was opgezet, dat het met een écht domein was en niet met een nep domein? Hoeveel procent zou er dan in hebben getrapt?

Ons antwoord op de vraag “Is XSS gevaarlijk” is een volmondig ja!

Het is mogelijk om te reageren op deze post. Houd het netjes

Bij toeval kwamen wij erachter dat de website van het NOS de IP-adressen van zijn bezoekers bekijkt. Komt deze in de regio van Nederland, dan krijgt de bezoeker de live-stream te zien en anders niet. FireFox heeft een prachtige add-on genaamd “X-Forwarded-For Spoofer“, waardoor oude systemen kunnen worden omzeild. Door een “nederlands” IP mee te geven (bijvoorbeeld “83.160.70.100″) kun je dus alsnog de stream bekijken!

Ondanks dat Chrome een aantal positieve dingen heeft (als een website vastloopt, loopt niet de hele browser vast), is het wél gevoelig voor hele oude phishing-aanvallen.

Als voorbeeld nemen we: http://hyves.nl/

Als u Firefox of een andere internet browser dan Chrome heeft, zal bovenstaande URL naar Hyves.nl gaan. Gebruikt u echter Chrome, zult op de website van SiteSafe komen…