Security via XSLT

bardofspoons421

My current project is dragging our product kicking and screaming into at least the early-to-mid 2000's. Part of this is making sure the pages look and function correctly in newer browsers, and rewriting a bunch of table based layouts, and IE specific Javascript.

The most legacy part of this project involves some VB6 COM objects that build up an XML document, request an XSLT over HTTP to the same server (Most of the time via the external DNS name of the server, resulting in a round trip from the server, to the border gateway and back), transform said XML into the XSLT, and them send that down to the client as a web page. Complete fustercluck when most of this app was contemporary with .Net 1.1 or higher.

A bit that shows this app's legacy as a VB6 Windows project is on quite a few forms, you've got Access style VCR controls (previous, next, first, last) for record navigation, and doing searches seems to be almost second class. These VCR controls were done completely table based, which broke when kicking IE out of compatibility mode, so a quick rewrite into a set of divs made the resulting HTML smaller. However, I noticed that the add button on this bar wasn't hiding all the times it should have been. A quick look at the button code in the XSLT shows this:

<button style="display:{$sAddDisplay}">                      
	<xsl:choose>
		<xsl:when test="Page/@PageType='Resident'">
			<xsl:attribute name="data-action">addresident</xsl:attribute>
			<xsl:value-of select="'Add Resident'" />
		</xsl:when>
		<xsl:otherwise>
			<xsl:attribute name="data-action">addapt</xsl:attribute>
			<xsl:value-of select="'Add Apt.'" />
		</xsl:otherwise>
	</xsl:choose>
</button>

Fair enough, but where is sAddDisplay defined? Not in this file, not in the XSLT-spaghetti that is the Utilities file. I finally find it in a file called Secuirty.xsl. How is it defined?

<xsl:variable name="sAddDisplay">
	<xsl:call-template name="GetVariableValue">
		<xsl:with-param name="Variable" select="'sAddDisplay'" />
	</xsl:call-template>
</xsl:variable>

And we need to go deeper, what on earth is GetVariableValue? A 520 line template, you say? It starts off like this, with PageName and PageType being hard coded strings in the VB6 code when the XML gets built for every request. Since every request is routed through a single ASP page, this is how the program figures out which COM object to call:

<xsl:template name="GetVariableValue">
	<xsl:param name="Variable" />
	<xsl:variable name="sPageName" select="$oRoot/@PageName" />
	<xsl:variable name="sPageType" select="$oRoot/@PageType" />
	<xsl:variable name="sOriginatingPage" select="$oRoot/@OriginatingPage" />

So, this one template returns a value for a variable based on one parameter, and three things that are constant per run of this XSLT. And the place that sAddDisplay is actually defined is within this mess (line breaks added by me, otherwise the test is all on one line):

<xsl:when test="$Variable='sAddDisplay'">
	<xsl:choose>
		<xsl:when test="$IsAdmin or ($oSecurity/Action[@Name='ModifyContact'] and $sPageType='Prospect') 
		or ($oSecurity/Action[@Name='ModifyReferrals'] and $sPageType='Referral') 
		or ($oSecurity/Action[@Name='UnitAdd'] and $sPageType='Unit') 
		or ($oSecurity/Action[@Name='AddResident'] and $sPageType='Resident') 
		or ($oSecurity/Action[@Name='UnitAdd'] and $sPageType='Unit') 
		or ($oSecurity/Action[@Name='ModifyAccount'] and ($sPageType='Account'))">display</xsl:when>
		<xsl:otherwise>none</xsl:otherwise>
	</xsl:choose>
</xsl:when>

Which, something you may have noticed if you were playing along at home: All this does is hide the button in the browser. The button is still emitted. There is no security checking in the VB6 code. Our product, which potentially has sensitive personal information in it, has security controlled by CSS, expressed via business rules implemented in XML.

Arnavion

To add insult to injury,

display: display

isn't even valid CSS.

@Arnavion said:

To add insult to injury,
display: display
isn't even valid CSS.

True. But sometimes "valid CSS" seems like an oxymoron.

Soviut

@El_Heffe said:

But sometimes "valid CSS" seems like an oxymoron.

No it doesn't. Valid CSS is well defined. Browser interpretations may not all be identical, but CSS as both a language and a spec is easy to validate. You have selectors that follow a strict set of rules, a finite set of properties, and each property has a finite set of values or value types. Further, the rules outlined for how certain properties will affect the layout of an element are quite clear.

Arnavion

@Soviut said:

You have selectors that follow a strict set of rules, a finite set of properties, and each property has a finite set of values or value types. Further, the rules outlined for how certain properties will affect the layout of an element are quite clear.

False and false. The various CSS specs are imprecisely defined in many places, in regards to both input and output. That's why (for example) some browsers allow apostrophes in some properties and others don't, why some combination of relative inside of absolute inside of relative inside of align: bottom looks different in different browsers, etc.

A quick Google search will give you examples. Here's a random one regarding allowed input: http://lists.w3.org/Archives/Public/www-style/2010Dec/0170.html (Read the reply too.)

@http://lists.w3.org/Archives/Public/www-style/2010Dec/0196.html said:

finding out that there are contradictions in the various specifications,
in this case one that is known but so far received no attention by the
working group, and in investigating those find there are changes pending
and some changes have been made quite some time ago that no browser has
since implemented. Add to that that typically browser vendors feel it's
best if they code their parser by hand (otherwise you don't introduce
enough security holes and conformance errors, I suppose) and then under-
stand why there has never been a single conforming implementation.

Here's a random one regarding output: http://ejohn.org/blog/sub-pixel-problems-in-css/

@http://ejohn.org/blog/sub-pixel-problems-in-css/ said:

The especially strange part, in all of this, is that there’s really no right, or wrong, here. How this behavior is supposed to play out by the rendering engine isn’t dictated by the CSS specification, having it be left up to the implementation to render as it sees fit. Obviously the four guidelines outlined by David, above, could serve browsers well but they are forced to sacrifice at least one of them in order to meet most of them.