Met NoScript ben je ook al tegen cross-site scripting beschermd :)

Op zich interessant, maarre het valt en staat met het feit dat alle browsers het moeten gaan ondersteunen. En niet dat we straks 10 verschillende beveiligingprotocollen moeten ondersteuen.

Dat hele gepruts met CSP heb je niet nodig als je simpelweg de 'gevaarlijke' characters in een URL verbiedt. Uit meer dan letters en cijfers hoeft een URL niet te bestaan (de characters / ? & en = daargelaten).

IE 8 beschermt ook (al ongeveer een half jaar) tegen XSS, zie http://blogs.msdn.com/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx

Ghostery is ook zo'n plugin.

Ghostery beschermd niet tegen XSS. Het blokkeert slechts bezoek-registratie-scripts zoals bijvoorbeeld Google Analytics.

Hoeft voor mij niet per se; ik draai hier al enige tijd NoScript.

Commentaar van de No-Script ontwikkelaar op http://forums.informaction.com/viewtopic.php?f=10&t=1790

-Do you think CSP is going in the right direction or is it simply a misstep that will further cloud the already foggy browser security landscape?

-I do not think it's a misstep at all. It would be great if it got wide adoption on the client, and especially on the server side (the two are strictly interdependent, obviously).
Notice, though, that its scope is very limited: while it's a great answer to XSS if correctly implemented on the server side (which is unlikely to be done better than current "secure development" best practices, except for larger sites with very good IT staffers), its merits against clickjacking are unlikely and it can't do anything against CSRF: that's why NoScript, ClearClick and ABE are orthogonal to CSP, rather than a competitors.

Zullen grote websites leuk vinden: uitermate praktisch voor het embedden van je media vanaf een CDN (alsook advertenties enzo)...



Mja, maar de XSS bescherming in NoScript is niet zo elegant dat 't de website vraagt wat "whitelisted" is -- daarin gaat 't net een bruikbaarder stapje verder.

Het probleem met veiligheid is dat je bruikbaarheid inlevert, NoScript gooit je website plat, als CSP degelijk blijkt te werken straks, kan alles optimaal blijven functioneren met veilige instellingen...


Helaas dat het ons niet beschermd tegen foute websites :-)

Alleen werkt dan niks meer.

onzin, xss wordt niet alleen geblokkeerd als de scripts van de gehele site geblokkeerd zijn... de anti-xss module zuivert de "verdachte" verzoeken, dus ook als je de gehele site alle scripts en plugins laat uitvoeren zullen XSS pogingen geblokkeerd worden

Als je je websites goed ontwerpt doe je het als volgt:

1. Maak een website die met kale HTML gewoon werkt.

2. Gebruik CSS om de vormgeving op te pimpen.

3. Gebruik JavaScript+DOM om dynamiek toe te voegen.

Als iets niet ondersteund wordt val je dan automatisch terug naar iets wat misschien wat minder gelikt is maar wel gewoon werkt. Graceful degradation heet dat. Ik ben het begrip voor het eerst tegengekomen op de website van het World Wide Web Consortium, lang geleden, toen ik webontwikkelaar was en me begon te verdiepen in hoe je CSS en DOM hoort toe te passen. Dat was in de tijd dat de incompatibiliteiten tussen browsers genoeg begonnen af te nemen om het zonder al te veel ellende toe te kunnen passen (ik ben begonen toen IE3-ondersteuning nog een vereiste was). Het is geen nieuw inzicht dus.

En wat zie je webdevelopers (of de hulpmiddelen die ze gebruiken) massaal doen? Hyperlinks maken die JavaScript nodig hebben om naar een andere pagina te gaan, terwijl dat gewoon een basismogelijkheid van HTML is. Formulieren maken die alleen via JavaScript gesubmit kunnen worden, terwijl dat gewoon een basismogelijkheid van HTML is (en validaties moet je sowieso op de server herhalen). Menu's helemaal vanuit JavaScript opbouwen, terwijl je ook die gewoon in HTML kan coderen en met CSS en JavaScript+DOM kan opfraaien. Redirects vanuit JavaScript doen terwijl dat via een HTTP-response of een meta-tag geregeld kan worden. Een toenemend aantal websites is zelfs zo stom om de "U heeft JavaScript nodig bij ons"-foutpagina zo op te roepen dat de pagina waar je op zat uit de browserhistorie verdwijnt, waardoor je na activeren van JavaScript niet makkelijk de gevraagde pagina terug kan halen. Gebruik van Ajax doet er natuurlijk ook een schepje bovenop, terwijl dat vaak wordt toegepast op manieren die vooral de cool-factor verhogen maar feitelijk geen functionaliteit (in inhoudelijke zin) toevoegen.

Een goed ontwikkelde website zou niet onderuit gehaald mogen worden door NoScript. Helaas is het concept van graceful degradation voor veel webontwikkelaars een ver-van-mijn-bed-show, of domweg te abstract om begrepen te worden. Ik ben overigens niet tegen het toevoegen van elementen die van JavaScript afhankelijk zijn, maar heb wel kritiek op het ervan afhankelijk maken van dingen die prima zonder kunnen. En let wel, dit beperkt je niet als webontwikkelaar. Je kan alle fancy toeters en bellen toepassen die je maar wilt, en toch een website neerzetten die bruikbaar is als een bezoeker JavaScript uit heeft staan; het sluit elkaar niet uit.

Vanuit dit inzicht is mijn eerste gedachte nooit dat NoScript een website kapot maakt, maar dat de website slecht gebouwd is.

dat ze eerst eenszorgen dat de zooi werkt in de spullen die er nu zijn
en dat ze XPI boeren eens vragen om hun spullen up2date te brengen, veel leuke spullen werken alleen nog met FF 2.x
en niet met 3.x

Het mooiste is nog dat een goed geschreven website geen last van cross site scripting heeft. En in de praktijk zitten de meeste van dit soort bugs in sites die uit behoefte zijn ontstaan en vaak niet echt ontworpen of uit afgeraffelde (delen) van een project. Dus eigenlijk door een gebrek aan aandacht en zorgvuldigheid ontstaat een probleem en de oplossing om dit probleem te verhelpen is dat er expliciet zorgvuldig een lijst moet worden opgesteld van toegestane acties? Een dergelijke systeem is misschien aardig als hardening maatregel, maar het is naïef om het een oplossing te noemen.