Nä jag läser om Cross Site scripting blir jag bara mer och mer trött på det hela... hur många specialtecken skall man behöva akta sig för?

Räcker det att inte tillåta några < eller > i strängarna som matas in av användaren? då är man ju skyddad mot ev. javascript som någon försöker flika in....

finns det ingen funktion som bara automatiskt tar bort alla specialtecken från en sträng i VBscript? Så man slipper sitta där med en hel rad

replace(var,',"")
replace(var,\,"")
replace(var,<,"")
replace(var,>,"")

osv osv...

men detta att inte tillåta dessa tecken kanske inte avhjälper problemet, eller..?

Ta inte bort specialtecknen. Byt ut dem mot säkra i stället.

< och > byts lämpligen ut mot &lt; resp. &gt; vid utskrift. Låt dem ligga oförändrade i databasen.

Som Per skriver, ta inte bort tecken utan validera att det användaren skriver in är rätt, eller ha kvar tecknen och lagra dem i databasen som de är. Sedan när du skriver ut det i HTML så kör du
<code>
Dim strText = "Detta är en text med <br />"
Server.HTMLEncode(strText)
</code>
HTMLEncode gör om alla osäkra specialtecken för HTML till säkra, alltså ersätter alla < > & ... med säkra motsvarigheter.

Detta innebär alltså att varje ställe där en användare har matat in något i databasen som senare visas på sidan kan han i dagsläget stoppa i html-kod eller (javascript om han gör ett tillräckligt kort) och fjanta till det eftersom jag inte kör htmlencode?

Fast det påverkar ju då bara hans sida och visning... så länge regeln gäller att man bara kan se information som man själv som inloggad har sparat, eller?

<b>Fast det påverkar ju då bara hans sida och visning... så länge regeln gäller att man bara kan se information som man själv som inloggad har sparat, eller?</b>

Ja, när det gäller HTML-injektion är detta sant. SQL-injektion kan dock påverka alla.

Tänk på att Server.HTLMEncode är envägs. Om du anropat så kan du inte återskapa texten som var innan.
Det är därför tänkvärt att spara värdet som det skrivs in och formatera det vid visning. JAg har det som vana att alltid formatera textfält vid visning.
Om det finns behov att få bättre prestanda kan man lägga till ytterligare ett fält där man lagrar det formaterade värdet.

Andreas, HTMLEncode är INTE envägs utan det går att ta tillbaka orginaltexten utan problem. Vanlig ASP har nog inte HTMLDecode funktionen om jag minns rätt, men .NET har det. Men skulle man behöva till ASP kan man skriva en egen funktion...

Men som sagt, det ska bara konverteras när man skriver ut det på sidan, inte när man sätter in i databasen...

Okej....

så om jag tar bort ' och \ från alla strängar som sparas, för att skydda mig mot SQL injection, och sedan dessutom hör HTML-encode på alla strängar som kommer från databsen som skall visas på sidan, är jag säker då..?

Finns det förresten andra anledningar till att folk skäller på mig att jag inte skall ta bort ' och \ utan göra dem säkra, andra anledningar än att användaren kanske menade och ville ha det där tecknet där?

Det är helt enkelt bara en oskriven regel att du inte ska i onödan ändra på det användaren skriver in utan i första hand validera data och låta användaren själv korrigera inskriven data om den är felaktig, eller helt enkelt godkänna att någonting sparas och formatera den så att den passar i förfrågningar till databasen eller utskrift i HTML på sidan.

Sen att folk "skäller" på dig kan ha att göra med att du bedömmer dig ha en 4/5 i kunskaper i ASP medan du frågar frågor som om du vore nybörjare. Självklart kan man aldrig allting, men man har nog hört talas om saker åtminstone om man tycker sig vara duktig.

Thomas, tack för att du rättade mig. Var inte medveten om att den även hanterade ampersand.
Därför antog jag att det kunde ställa till med stränga där redan escapade tecken förekom, så som:

Test = Server.HTMLEncode("&lt;<&gt;>")

jo, det finns väl mer till ASP än man trodde.. =)

Det finns mycket inom allt, men det betyder ju inte att du är "usel" på allt. Viktigt är ju att kunna bedömma vad man egentligen kan och vad man kan mindre bra/säkert.

Men självklart är det svårt att bedömma sina egna kunskaper. Menade inte att "skälla" på dig tidigare, så ta inte åt dig av det. Det finns värre typer här som tycker de kan mer än de egentligen kan.

För övrigt rekommenderar jag, vilket språk du än skriver i, att du först validerar indata, gärna på klientsidan men absolut på serversidan innan du tillåter att det ens hamnar i processen att sättas in i databasen eller skrivas ut på sidan. När du sedan skriver in i databasen gör du strängarna säkra, eller använder dig av parametrar, och använder dig av HTMLEncode på all data som skrivs ut på sidan.