I read somewhere about making sure the charset was what you want, like
iso-8859-1,
so that your filter doesn't get circumvented by a different charset and
subsequently, malicious code getting rendered.
Do you know what I mean by this?
If so, do you know how to enforce this?
-Joe
Laurie Harper wrote:
Joseph McGranaghan wrote:
Better safe than sorry ;-) As someone else posted, though, you also
have to be wary of things like "java\nscript:alert('scripty')" in
attribute values and other 'interesting' variations. Same for CSS
style rules. As mentioned above, IE supports invoking behaviour from
CSS.
Ya I mentioned this. I a regex like so: "java\\s*script"
Needs to be case-insensative.
That's not sufficient though. As I pointed out in my last post, there
are lots of ways of 'fooling' that check. For example,
'java&#xx;cript' (where 'xx' is the Unicode code point for the letter
's').
Also, if you have more than one application attached to the same
database, and any one of them has a faulty input filter, SQL
injection bug or whatever, it will result in all your apps being
exposed / affected.
Nice, I'll keep that in mind.
Right now my db is on the same server though, so I don't believe this
is a problem.
Am I wrong?
It doesn't matter what server the database is on, it matters how many
sources of HTML input there are. If you only have one app connecting
to that database, the point is moot.
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
