Oops, bad example. I guess this is generally more of a problem in a case
such as .
Script injection through CSS is an IE-specific vulnerability; it
supports a non-standard style property (called behaviour? can't recall
off hand) which can execute, at least, Javascript.
L.
Adam Ruggles wrote
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 Har
/Nope. What about ? Or
Javascript injection through CSS in IE? What about any new Javascript
injection mechanism that some browser adds down the line... ;-) /
Which browser did you get this injection to work on? Other than fixing
the misspelling of alert, I couldn't get the javascript to exec
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
Down below...
Laurie Harper wrote:
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joe,
Joseph McGranaghan wrote:
So, tags I'm originally NOT allowing are:
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joe,
Joseph McGranaghan wrote:
So, tags I'm originally NOT allowing are:
Thanks for the feedback Chris.
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joe,
Joseph McGranaghan wrote:
So, tags I'm originally NOT allowing are:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joe,
Joseph McGranaghan wrote:
> So, tags I'm originally NOT allowing are:
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joe,
Joseph McGranaghan wrote:
> Ok, this is my argument for filtering input:
(Note that I'm sure we can argue all day over whether input vs. output
filtering is better; I'd prefer to state my opinion and get on with it).
> 1) I don't want bad code
--- Leon Rosenberg wrote:
> Hmm, the OP said:
>> I am trying to find a best solution to prevent
>> Cross site scripting attacks.
Oops. Yep, I guess I latched on to the discussion
after the "but I need to allow markup" bit; sorry.
> Allowing the user to inject HTML markup in your
> pages is the ro
Ok, I'm going to pay attention to the problem, the XSS filter:
I am using a 'blacklist', because my users need to enter as much X\HTML
as I can possibly allow them.
So, tags I'm originally NOT allowing are:
--- Joseph McGranaghan <[EMAIL PROTECTED]>
wrote:
> I guess I just don't see an argument for filtering
> it on the way out. What if you miss something?
Couldn't you miss it on the way in, too?
d.
We won't te
Ok, this is my argument for filtering input:
1) I don't want bad code (javascript or other) making into my db in the
first place, ever.
2) You have to validate as input comes in anyways and THIS is where your
validation logic is housed:
- if field is Date, check it; 'username' then ^
Hi Dave,
On 3/16/07, Dave Newton <[EMAIL PROTECTED]> wrote:
--- Leon Rosenberg wrote:
> And even with an rdbms, have you ever tried to
> update like 1.000.000 rows of an in production db
> under traffic?
Stuff like that happens all the time, although I tend
to do such things at low-traffic time
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dale,
Dale Newfield wrote:
> Christopher Schultz wrote:
>> If you /are/ capturing text you will be using that /can/ contain HTML
>> markup, then cleaning it as it comes in is still a mistake. Let's say
>> you have a bug in your cleansing code. In that
--- Leon Rosenberg wrote:
> And even with an rdbms, have you ever tried to
> update like 1.000.000 rows of an in production db
> under traffic?
Stuff like that happens all the time, although I tend
to do such things at low-traffic times or on a
replicated DB (yeah, moving it back takes time too,
On 3/16/07, Dale Newfield <[EMAIL PROTECTED]> wrote:
There are two discussions here that are getting convoluted: WHEN to
"clean" and HOW to clean. I still have yet to find a good comprehensive
way to do the latter (more below), but right here I'm responding to the
former.
Christopher Schultz w
There are two discussions here that are getting convoluted: WHEN to
"clean" and HOW to clean. I still have yet to find a good comprehensive
way to do the latter (more below), but right here I'm responding to the
former.
Christopher Schultz wrote:
If you /are/ capturing text you will be usin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joseph,
Joseph McGranaghan wrote:
> I [hear that worrying about XSS is not worth it] all the time, am I
> missing something?
>
> What if you want the user to be able to input all kinds of
> markup to be redisplayed:
>
>
>http://somewhere.com";>
--- Joseph McGranaghan wrote:
> [... huge-ass regexp, including...]
> |c(?:hange|lick)|
IANAREW, but... what's with all the weird "let's
refactor out the first (and/or) last characters of the
regexp?"
This seems like a really slow, really... weird way to
deal with XSS.
d.
_
rry about.
Basically the whole discussion is useless, its sufficent to encode <
and > properly :-)
Leon.
-Original Message-
From: Joseph McGranaghan [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 4:46 PM
To: Struts Users Mailing List
Subject: Re: Cross site scripting
gt; properly :-)
Leon.
-Original Message-
From: Joseph McGranaghan [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 4:46 PM
To: Struts Users Mailing List
Subject: Re: Cross site scripting issue
Sorry, just noticed a problem in that events filter.
(;|>) in the end should be
ssage-
From: Joseph McGranaghan [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 4:46 PM
To: Struts Users Mailing List
Subject: Re: Cross site scripting issue
Sorry, just noticed a problem in that events filter.
(;|>) in the end should be just >
in case multiple statements.
Sorry, just noticed a problem in that events filter.
(;|>) in the end should be just >
in case multiple statements.
It's a work in progress :)
-Joe
Joseph McGranaghan wrote:
I'm currently working on this problem for a website I'm building.
I found this:
on(?:(?:mo(?:use(?:o
I'm currently working on this problem for a website I'm building.
I found this:
on(?:(?:mo(?:use(?:o(?:ver|ut)|down|move|up)|ve)|key(?:press|dow" +
"n|up)|c(?:hange|lick)|s(?:elec|ubmi)t|(?:un)?load|dragdrop|resize|focus|" +
"blur)\b\W*?=|abort\b)|(?:l(?:owsrc
rapsy wrote:
I am trying to find a best solution to prevent Cross site scripting attacks.
Aren't we all.
The best suggestion I've found is in the first comment on
http://weblogs.java.net/blog/gmurray71/archive/2006/09/preventing_cros.html
Basically the suggestion is to Tagsoup parse into XH
You should check out this site:
http://iamcal.com/publish/articles/php/processing_html/
It's in PHP and Perl, but it only took me a couple of hours to translate
it to Java.
Sami Dalouche wrote:
Hi,
If you want to escape HTML, you can use Jakarta Commons-Lang
StringEscapeUtils class :
http:/
Hi,
If you want to escape HTML, you can use Jakarta Commons-Lang
StringEscapeUtils class :
http://jakarta.apache.org/commons/lang/apidocs/org/apache/commons/lang/StringEscapeUtils.html#escapeHtml(java.lang.String)
Personally, I am using the Radeox Wiki engine
(http://www.radeox.org/space/start) t
Are you allowing the user to redisplay any entered HTML ala myspace?
I'm working on a solution for this right now. For this situation, I'm
filtering it in action before it is saved to DB.
Here are some REs and a simple function:
private final static String XSS_BIG_OBJECTS_FILTER =
"(((<\\s*
Jason Britain (author of Tomcat, the definitive guide) has a
ready-to-run filter/valve solution for that. You could talk to him on
the #tomcat channel on irc.
Besides, best XSS prevention is imo not filtering the input, but the
output. if you write everything out with you'll be fine.
regards
Le
Check for a predefined pattern of characters in a filter,as you have suggested,
(probably read from xml) and forward to an error page if you find any.
-Original Message-
From: rapsy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 14, 2007 3:50 PM
To: user@struts.apache.org
Subject: Cross
31 matches
Mail list logo
