Groups > comp.lang.javascript > #20396

Re: How to detect that or determine if your server side script or javascript has been hacked?

Message-ID	<2505650.gy7AA5UhkT@PointedEars.de> (permalink)
From	Thomas 'PointedEars' Lahn <PointedEars@web.de>
Organization	PointedEars Software (PES)
Date	2013-06-22 18:13 +0200
Subject	Re: How to detect that or determine if your server side script or javascript has been hacked?
Newsgroups	comp.lang.javascript
References	<e5abd2fe-dd94-4d84-8bad-277d87c242a9@googlegroups.com> <XnsA1E79A10E952eejj99@194.109.133.133> <fa737844-ec4d-4581-9c32-82e366b4eb96@googlegroups.com> <kq47s3$jor$1@dont-email.me> <timstreater-A5603B.15244722062013@news.individual.net>

Show all headers | View raw

Tim Streater wrote:

> Denis McMahon <denismfmcmahon@gmail.com> wrote:
>> […] Is your HTML validating?
>> 
>> Remember that Javascript acts on the document node tree that the browser
>> generates from your html by using the dtd that you specify. If your html
>> isn't valid for that dtd, then the browser may be applying your
>> javascript to a document node tree that doesn't match the one you wrote
>> the javascript to work on.
> 
> Do browsers do that, read the dtd?

It depends on the markup language, the used parser, and the parsing mode.  

For (X)HTML5 there is no (formal) Document Type Definition (DTD), but there 
are standardized parsing rules. [1]  If an author ignores those rules, the 
result is probably not what they wanted.

For HTML 4 there are DTDs [2], but few parsers work strictly according to 
those.  However, I remember vividly from several years ago a stylesheet rule 
“working” in Internet Explorer (when it should not have worked) and “not 
working” (when it should have worked) in Firefox.  The reason was that the 
resulting document tree was different in Internet Explorer than in Firefox 
because of different error correction of invalid markup, and then in IE CSS 
rules were applied that never were intended to apply.  The corresponding 
developer tools showed me.  This taught me two things if I not already knew 
them at that point:

  1. Never blindly trust source code.  Not your own, and especially not
     foreign code.

  2. Always validate your markup and stylesheets before complaining.

For XHTML 1.x, 2.0, and other XML applications there are DTDs, and not 
following the DTD may result in a syntax error so that the document is not 
further processed at all. [3]  This is particularly true for parsing XHTML 
when served with an XHTML media type that is _not_ “text/html” [1], and for 
SVG and MathML.

> I thought they only cared whether there was a doctype or not, and ignored
> its contents.

No, there are *at least* parsing rules that are *based on* the respective 
language Specification in order to make the best sense of even formally 
erroneous markup.  Ignoring that Specification is risky, as error correction 
is not (fully) standardized and certainly not interoperable.  This is why 
there are validators, e.g. [4] and [5]. [6]

Also, there is the “DOCTYPE switch” feature that determines the *rendering* 
mode depending on the content of the (pseudo-)DOCTYPE declaration. [7]

For client-side DOM scripting, it also affects which properties are 
available where (document.documentElement.* vs. document.body.*) and what 
values will be functional (e.g., non-zero lengths with vs. without unit on 
style properties).

________ 
[1] <http://www.w3.org/TR/2012/CR-html5-20121217/syntax.html#parsing>
[2] <http://www.w3.org/TR/1999/REC-html401-19991224/sgml/intro.html>
[3] <http://www.w3.org/TR/2008/REC-xml-20081126/#proc-types>
[4] <http://validator.w3.org/>
[5] <http://jigsaw.w3.org/css-validator/>
[6] 
<http://wayback.archive.org/web/20110925033612/http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you>
[7] <http://www.quirksmode.org/css/quirksmode.html>
-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

Thread

csiph-web