XSS vulnerabilities created by Microsoft Publisher and other applications - what to look out for, how to prevent it.

Hi all,  have you ever used a mainstream publishing application such as Microsoft Publisher to create a document?  Did you ever decide you want to publish it to the internet?  Be aware that many WYSIWYG applications create "bad HTML" - The created code may have internet vulnerabilities you never dreamed of.

XSS and even other security threats - explained, explored, prevented:
Hit it "E"-"E"-ers
Who is Participating?
ahoffmannConnect With a Mentor Commented:
well explained rdivilbiss.

But quoting HTML attributes does not prevent from HTML injection and XSS at all. (BTW, nice to see that someone distinguishs here).
The problem is not the HTML code itself, but the generator of the code, which has to do proper data validation for output.
For example a HTML tag like <input name=name value="replace me"> can simply be subject for HTML injection when giving it a value of   "><p>heureca, broke the code</p na="
Same could be done for XSS and so on.

Again, static pages are not the problem at all, doesn't matter how good or bad the HTML code is. But any kind of dynamic pages are subject to such vulnerabilities. Dynamic can be CGI, SSI, ASP, PHP, JSP, or whatever you use ...
rdivilbissConnect With a Mentor Commented:
Publisher does not quote HTML attributes, which is potentially an XSS - HTML Injection issue and certainly not compliant with current W3C recommendations (e.g. HTML 4.01 Strict, circa 1998)

To stay within the confines of the membership agreement, I won't post real code, just an overview and not to specific.

Let's say you have an e-commerce site and you didn't quote your attributes.  I'm a phisher and I frame your site (hiding my frame), do a little URL spoofing (common knowledge) and basically coax people to your page within my frame.  We all know that is possible.  Happens every day, especially with banking sites.

I could, for example, use a little HTML injection to add additional handlers into your unquoted event attribute... say you have a mouseover/mouseout for highlighting the currently focused input, I can add that the value of the field is sent to my frame...usefule for credit cardnumbers.

A small example and I don't think I gave you enough detail to exploit it or even prove it is possible.  The best examples I saw were in an article I'm having trouble finding, however Writing Secure Code 2 has some examples.

You can have a lot of fun with "src" attributes in embeds, objects and images.

Searching for "HTML injection", and "html attribute XSS" on google will find some good examples.  Unfortunately you'll also have to wade through a lot of discussion relating to posting HTML in forumns, etc. which is not what we are talking about here.

Even if you negate the HTML injection/XSS aspect, you should still quote all attributes for validity reasons.

Strictly speaking you are non-compliant (4.01 strict) without the quotes and you must have them for XHTML and XML so you might as well get in the habit.

Hope that helps some.
C_WitAuthor Commented:
Thank-you to the both of you,  good information.  How do you feel about splitting points?
rdivilbiss 320,  ahoffmann 180,  sound fair?
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

I am okay with whatever you decide.

C_WitAuthor Commented:
Does anyone have a recommendation for a general read on this subject?
A semi-comprehensive article on top things to look out for, or how these vulnerabilities can be prevented & even exploited would be great!
general read about what? XSS and Microsoft something, or XSS in general.
C_WitAuthor Commented:
I guess top/most common vulnerabilities pertaining to HTML and frequently used web components or just more information about things like the following statement:

"HTML attributes does not prevent from HTML injection and XSS at all. (BTW, nice to see that someone distinguishs here)."

(Hard for me to ask much about it, when I know little about it.)
ahoffmannConnect With a Mentor Commented:
hmm, would be a long list ...
I'd start at
  http://www.owasp.org/   with the Top Ten List
C_WitAuthor Commented:
C_WitAuthor Commented:
I just took a quick look at the websites you mentioned above...  looks like good info./stuff.

Could you explain your previous statement a little bit more for me?
you stated:
"For example a HTML tag like <input name=name value="replace me"> can simply be subject for HTML injection when giving it a value of   "><p>heureca, broke the code</p na="  Same could be done for XSS and so on."


> Could you explain ..
As I said, static pages are not the problem, but dynamic generated pages using input provided by the user.
For example if you have a page which accepts input and the input is returned as part of the aswer page, like

   <input type=text value="returned input">

  returned input
is what was given by the browser. Look what hapens if you replace this string with my heureca example, simply write it down verbatime and you see ;-)
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.