The Forgettable Mister Ruthsarian

Revisitation

UPDATE #1:
I found a solution. IE 5.0 does do overflow: hidden just fine. So I can use an empty comment hack to set this rule in IE 5.0 and use the more correct overflow: visible in IE 5.5 and 6.

The pros: no horizontal scrollbars, no dropped columns.

The cons: 1-5 pixels (or so) of the text box containing the italics will get clipped and hidden.

UPDATE #2:
Thank the maker for this blog. It gives me a place to rant about a specific problem. And when I do that it gives me an exercise to organize my thoughts. I can usually go find a solution after I bitch on here, and this time is no different. This overflow hack is working beautifully in IE 5.0.

UPDATE #3:
Of course.. if you have hidden overflow, anything that normally goes beyond the borders of the column like, oh I don't know, a drop down menu will be hidden as well. *sigh*

I did find another workaround that keeps the columns from dropping, but it leads to a horizontal scrollbar under certain conditions (viewport widths). But it's targeted at IE/Win 5.0 only. So maybe that's a decent compromise.
--

So my thought was/is to revisit Skidoo Too and update it, throw in a few new bits, maybe add a page of actual instructions on how to use and implement the layout. But first I wanted to rework the CSS and my traditional means for that is to simply start over from scratch.

So that's what I've done. Immediately I find new ways to structure the markup (not major, minor changes really) and new ways to structure the CSS. This time I wanted to document as much as possible on all the bugs I encountered. Early in the process I've discovered something that's a bit disheartening.

This is a bug, a very old bug, in IE that has regarding italicized text (maybe bold too? or even text-transformed text? never tested that). What happens is the width for a given line of text is calculated without figuring in the increased width of the italicized text. And as IE resizes parent elements to make their children fit, the parent of an block of text with italics will be increased in width to make room. In CSS layouts that are "pixel perfect" this creates a big problem. Floated elements (columns) are dropped down until there's room enough to fit.

I had found early in the development of the original Skidoo that setting the overflow property on these floated elements resolved the issue nicely. But not.. it seems.. in IE 5.0. Even with the overflow property set the columns are still being pushed down.

Now the easiest solution is to simply not use italics at all, but that's very unrealistic. So now what?

Under specific conditions all Skidoo-related layouts break in IE/Win 5.0. This is a bit frustrating. I can't seem to find a workaround.

I know it's IE 5.0.. it's many years old and the number of people using it today have got to be relatively small, but still...

IE7 Menu Bar

There's a way to put the menu bar at the top of the IE7 window. This page of IE7 tweaks includes a registry file which does the job. There should be an easier way to do this and there probably will be one in a later release, but small things like this show IE7 devs lost focus on usability.

Firefox 2.0

Firefox 2.0 is scheduled to be released this afternoon. The install files have already been found on Firefox mirror sites if you want to get the jump on things, otherwise just wait a few more hours.

Among the new features is a spell checker used on all textarea fields. If you misspell a word a dotted red underline appears. I think that's brilliant. If you right-click on the misspelled word Firefox will give you a list of possible replacements. Tabbed browsing has been updated a bit with the ability to undo closing a tab. The history menu also has a recently closed tabs section now.

Looks like a solid release. Still miles ahead of IE.

IE7 Officially Released

Here it is:
http://www.microsoft.com/windows/ie/downloads/default.mspx

Downloading and installing now. I don't expect much difference to what we saw in RC1. We'll see.

--

Update

Well it's installed. The software uninstalled IE7 RC1, then rebooted. Then downloaded and installed the new IE7. Then rebooted.

When I finally got my desktop back some of my desktop settings had been changed. My quick launch toolbar was gone and the resolution on my secondary monitor (I have a dual-monitor setup) had been changed to what it'd be pre-IE7 beta install.

Some of my IE7 RC1 settings stayed. Others, like anything relating to the really annoying phishing filter were reset.

I still can't move the FILE menu bar above the navigation/address bar. That really annoys me.

All the bugs in IE7 I've been talking about in past blog posts are all still there, as you can see by checking the IE7 bug demo. It's a bit dissapointing.

Essentially IE7 is IE6 with some cosmetic changes and some minor updates to it's CSS parser and rendering engine. It's still the same old buggy hasLayout-based engine it's been since IE5. You'd have thought they'd of done more with the core of the browser given the time and resources the IE dev team had. Instead they just bloated it up with new privacy/security bits that are just annoying.

Tabs are nice. The zoom feature, which doesn't just increase text size but increases the size of everything is nice. The "delete browsing history" feature is nice in that you can select what bits are deleted (cookies, history, form data, passwords, etc..) similar to FireFox.

But it's all been done before, with the exception of the built-in phishing filter you won't find anything groundbreaking in IE7. And to be honest I don't think the phishing filter is groundbreaking, I think it's going to prove ineffective in time. It's annoying when you use it so users will eventually turn it off and then it'll do nothing at all. It probably won't catch "0-day" phishing sites, and I think it'll provide a false sense of security for those who do have it enabled. Grandma might be more willing to provide information over a web form on a site that IE7 doesn't explicitly state is a phishing site. I don't want grandma to get lazy and let her guard down when she's surfing the web. She needs to remain suspicious of every site that asks her for any information at all. Will she let her guard down because of IE7's phishing filter?

If Microsoft were really interested in preventing such things I'd much rather see some sort of education program. Maybe once-a-month have IE pop-up with a message that brings the user to a site or page that talks about some small section of safe browsing, like phishing, or spyware, or whatever. With the kind of userbase IE has I think such an approach would reach a large number of people. And by educating users on what "phishing" means rather than just throwing on some tool called a "phishing filter" when half their user base probably doesn't even know what that means, could really make a difference in keeping users safe, really safe, from malicious websites.

It's the one thing everyone seems to skip. Education. I'm part of a security team where I work and every month we meet and go over what we're doing to help increase and/or maintain a high level of security. The one thing I have to keep bringing up at each meeting, the one thing everyone very quickly forgets, is education. Everyone wants to install new programs that will protect users from themselves. The problem with that is as attacks (social and computer) evolve, these programs will not (or at least lag-behind the evolution). An educated user would be more ready and more easily adapt to the evolution of these attacks than a program.

But nobody seems to really care about educating users on safe computing practices. Nobody wants to try. And that, more than the this release of IE7, is depressing.

Ruthsarian Menus : It's Official

Ruthsarian Menus are officially released. Woo!

I've put together a bit of a write-up on the system although it's the stylesheet where all they key bits are. Lots of detail on bugs I encountered and how I worked around them, etc..

I need to actually re-read what I typed up later today, after I've been away from the topic for a little while. I just wanted this thing "officialized" as soon as possible.

In other news I sent yet one more e-mail off to Microsoft about bugs. This time it was about the rounding errors I'd come across in the past.

I actually got a response!

From the MS mail server saying one of the two guys I was given contact info for was no longer able to receive e-mail.

But then I actually got ANOTHER respopnse! This time from a real person! He told me that this bug was going to be around a while and definately there in IE 7's final release. He made mention that the CSS spec doesn't cover how rounding should be handled; said he hadn't looked at what Mozilla was doing, but had some idea how Opera handled it.

Oh well.

At least I know there's a real live person at the other end of that MS e-mail address I was given.

Good Enough

rMenu is pretty much ready. I've thrown in the last few bits to get IE7 working properly.

I've decided to use negative top margins for vertical positioning of dropdowns to workaround iCab's problem with initial rendering of elements positioned with the top attribute.

However the Opera pre-7.5 positioning bug that affects right-aligned horizontal menus I'm leaving and won't be fixing, at least not right now as I can't find any easy way to do it. I'm not bothered by this because 7.5 is a few years old and most Opera users will have upgraded by now.

iCab I wanted to fix because it's most current version has this bug and I felt it important to get at least most current version of the more popular browsers working with this menu system.

I have already incorporated this new menu system with Tank!. I just need to create a quickie utility stylesheet for the two-column setup used in the main column of Tank! because what's there now doesn't work in IE 5/Mac. The two-column setup on the rMenu demo page does work with IE 5/Mac so I'll just copy it over and Tank! will be ready to go.

And then I'll be done with it for now and move onto something new. I'm not sure what yet. All I know is I'd like to either try something that's visually interesting but doesn't use so many boxes, or go for some radical design. Just something new. I won't know until I'm half way designing it what it'll be.

CSS Discuss is back up and running and my post to the list about rMenU went through. Number of responses: 0. So I'm on my own. The Opera 7 issue I'm going to ignore because I doubt there are many 7.23 (or earlier) Opera users still out there and because there probably isn't a real fix. iCab I'll toy with and see if I can work around it's rendering bug. Opera 9.02? I don't know. The menus don't break, you're just forced to move over the text in the buttom in order for the link to work. Maybe it's a z-index thing? I"ll play around and figure it out myself.

In The News

IE7 is going out October 18th.

Skidoo Too is in the news (sort of). A company that produces software for college/university housing needs is using Skidoo Too and the software made the news. I just wish they'd change the default colors. You can only look at "minty fresh" for so long before you get really tired of it.

I wanted to send a note to the css-discuss mailing list to see if anyone had any ideas about solving my Opera 7.23 and iCab problems with rMenu but the list appears to be dead. Looks like around 9 AM EST on Monday the list just stopped sending alltogether.

Oh well.

IE7 Tomorrow?

It seems that IE7 might be pushed out to users tomorrow as a high-priority update. Automatic updates enabled? Well you're getting a new browser.

I think it's fair to say that none of the CSS bugs in IE7 that I'd ranted about earlier have been patched. Haven't heard back from the IE guys either. Odd that they'd release it this soon rather than push out an RC2 version first.

Sigh.

rMenu Bits

The Opera 7.23 and earlier issues relate to a bug in pre-7.5 versions of Opera that position relative to the root document and not the parent of the positioned element.

iCab seems to have a wierd bug regarding the top attribute. It renders drop-down menus at top: 0 regardless of what top is set to. Once you mouse-over the drop-down menu it'll reset itself to the right position. The odd bit is if I mouse-over the LI with a drop-down menu in it from different directions the drop-down renders correctly. I got no clue what that's about.

Opera 9.02 seems to be dropping focus through LIs that are over text. This is similar to the IE bug I talked about a week ago. I submitted a bug report.

Javier, the experiences you're describing with IE6 are not shared with others. I've tested it on 10 different machines here at work that run IE6 and none of them exhibit any sort of rendering defect. And aside from the focus issue, I saw no problems in Opera 9.02.

So I've got no clue what to make of that.

rMenu Getting Better

rMenu now works on IE/Mac 5.0 and 5.2. 5.0 seems to require the user reload the page once to get it working but after that it works flawlessly. Known working with this menu system:

• FireFox 1.5
• Opera 7.54, 8.5
• Netscape 7
• IE/Win 5.0, 5.5, 6.0, 7 RC1
• IE/Mac 5.0, 5.2
• Safari 1.3.2

iCab and Opera 7.23 have bugs that I'll need to iron out. Have yet to test Konqueror but hopeful since Safari works fine.

IE/Mac Oddities

The new rMenu was using classes such as rMenu-v for vertical menus and rMenu-h for horizontal menus. To simplify the CSS a bit I then added, for this new version, a few more classes such as rMenu-vRight to signify a vertical menu that is right-aligned.

This worked great, until I got to IE/Mac 5.2. It seems 5.2 (probably 5.0 as well) has a problem with it's parser. Rules set for rMenu-v were being applied to objects with the class rMenu-vRight. It's as if, instead of checking the full class name IE/Mac is just looking for the string of a given selector among the group of classes an object is assigned to.

So I've had to rename some classes. rMenu-v is now rMenu-ver and rMenu-h has become rMenu-hor and that seems to have worked around the problems.

Silly.

rMenu Revised

Update: rMenu link fixed.

First, Javier, I do know about cfqueryparam. The reason I think CF sucks in some areas are:

1. The way it handles evaluations in CFQUERies and not properly escaping like it should, as demoed in my previous post on CF
2. The third-party SequeLink app, which manages database connections and queries, is very unstable. It crashes at least once a month, which brings down the entire website.
3. The amazing amount of openness it has with a default install. Tags like CFREGISTRY and CFEXECUTE shouldn't even exist, let alone be open for abuse. CFSCHEDULE shouldn't exist either.
4. It's easy to exploit locally. Using CFOBJECT you can create JAVA objects used to encrypt the database passwords stored in the system to then unencrypt them. This has saved my tail when we lost the passwords for a couple old datasources, but anyone else with access to edit files on the server could just as easily have done it.
5. "Encrypted" CFM files are a joke
6. The syntax is too forgiving. When to use and not use hash/pound symbols? CF doesn't care, stick them anyplace you want.
7. Things like CFPARAM. Too many crutches that lead to lazy programming.
8. Ever-growing infection of Flash in ColdFusion.
9. Too resource intensive. You want to crash a server running CF or at least perform a basic DOS? Go find a CF server, load up a page, then reload the page repeatedly. You'll very quickly max out the number of concurrent processes allowed on the server and the process queue can be easily maxed out. On that same box, I can run a PHP application that has the same UNCACHED db queries (the CF app using cached queries) and perform the same stunt and the server will stay up and show no sign of lag. Unless you're running a quad-Xeon machine with 100gb of RAM, CF won't be able to keep up.

That's off the top of my head. I'd have more if I wrote them down as they happened.

rMenu

rMenu has been updated. I've put up the latest copy of the CSS based on my latest work with IE, etc.. and it's a bit simpler and cleaner than before and doesn't have any of the bugs under IE7 that the old version had. I haven't tested it on a Mac platform yet but I'm 99.9% certain it's broken under IE/Mac. However Safari should be fine and platform-independant browsers like Opera and FireFox should work fine. iCab I'm not sure about and Konqueror I'm not sure about. Hopefully I can work on testing that out tomorrow. But I think I'm close.

More IE Oddities

I've started a rewrite of the rMenu system based on what I've learned about IE and hasLayout in the last couple weeks.

One problem I encountered was with borders. I like to wrap a border around each menu item to distinguish each one and provide some visual border to the menu. Typically I'd wrap an anchor or parent LI in a border and then apply a negative 1px margin on the bottom of each anchor or LI for vertical and right for horizontal menus. This keeps borders from doubling-up when two items are next to each other. The problem was that IE6 (and earlier) would drop the border on the extreme edge (the bottom-most or left-most item) of the menu. So then I'd try applying borders without the use of negative margins, such as applying the UL with a border on 3 of the 4 sides, and apply all LI or A elements with a border on that 4th side. This works well for vertical menus but not horizontal menus. The reason is horizontal menu UL elements are blocks and, thus, run the full width of the page. The LI elements are floated. So the top and bottom borders will always be wider than the actual width of the menu.

Long story short, here's what I've come up with. I've applied a border on all four sides of the anchor elements. I then apply a negative margin on the parent LI element. Because the negative margin is on a different (parent) element, IE6 (and earlier) won't cut off the extreme edge. Great! Problem solved!

Not so fast.

Vertical menus that have a negative bottom margin on the LI elements creates the same text-jog issue seein in menu #3 of the IE7 demo I prepared for Microsoft. In that instance, triggering hasLayout on the anchor elements resolved the issue. But now I've found that even with anchors having layout the bug can still be triggered. So it's not a hasLayout issue, but something else entirely.

But there is a fix. It seems negative TOP margins are okay. So setting a negative top margin on the LIs still gives the overlapping of borders I want on IE6 and IE7 but without triggering the vertical text jog found in IE7.

It's ridiculous.

But let it be known, that vertical text-jog seen in that IE7 demo is NOT directly related to hasLayout. Rather forcing the child anchor to have layout forces something else to happen on the parent LI element that prevents this text jog.

I really can't wait to be done with rMenu. I want this monkey off my back.

ColdFusion: CFQUERY and Evaluate()

Been going back and forth with a friend who does CF development for some company. Anyways, he rings me up to talk about some SQL injection attacks that have been reported on an application he maintains. I take a look at the code and, sure enough, there are. Problem is they're buried a bit and not easily found. Furthermore, one of the two exploits I'm about to cover is something not many CF developers will ever notice, even if they are aware of the dangers of SQL injection. This is because ColdFusion, on some levels, sucks.

Case 1: Evaluate

Here's the code:

<cfset session.isadmin = false>

<cfparam name="url.x" default="1">

<cfset variables.msg1 = "Welcome To Our Site">
<cfset variables.msg2 = "Site Administration">

<h1><cfoutput>#Evaluate( "variables.msg#x#" )#</cfoutput></h1>

<cfif session.isadmin is true>
  <p>You may now administer the site as you see fit.</p>
<cfelse>
  <p>Buy our product.</p>
</cfif>

This is now how you write CF, this is just a very simplified example to show you the problem that was discovered; in this case, it's the Evaluate() line. Variable X is being passed on the URL in this example for simplification. In reality, there are any number of ways user-provided data could find it's way into an Evaluate() statement. I'm just making it easy and obvious here.

Evaluate() will evaluate (and execute) the contents of the string that is passed to the function and return the result. The intention of the example above is to return the relevant message associated with the user's level of access. Since X is supplied by the user it is possible to inject something into that Evaluate() line. But what?

Long story short, calling this script with the following URL will alter the isadmin session variable to change the user's access level.
vulnerable.cfm?x=2+eq+'a'+or+SetVariable(session.isadmin,true)

This creates the following Evaluate() statement:
Evaluate( "variables.msg2 eq 'a' or SetVariable(session.isadmin,true)" )

The string now represents a boolean statement. Instead of returning the value of the string variables.msg2 it now will return TRUE or FALSE. And before it does that it will execute every expression in the statement, including a call to the function SetVariable() which alters the isadmin session variable. With that, the user is now an admin and will have full control of the application. What's worse, more function calls could could be passed to the application which essentially give the user the same level of access to the machine as whatever user ColdFusion is running under. Especially under ColdFusion MX where CreateObject() can be used to create JAVA objects that provide system-level access.

Case 2: Evaluate in a CFQUERY

<cfsetting showdebugoutput="Yes">
<cfset variables.hack = "' OR 1=1 OR Name='">
<cfquery datasource="misc" name="test">
  SELECT *
  FROM Test
  WHERE Name = '#Evaluate( "variables.hack" )#'
</cfquery>

Again, I'm oversiplifying this a bit, but I'll show you where this would happen in the real world once you understand what's going on here.

variables.hack represents the point of injection. We assume this variable has a legit purpose but, at this point in the code execution, it's value has been altered by a malicious user to what it's set as in the code. The relevant portion of the SQL injection is OR 1=1 OR which will trigger the database to return all records instead of just the one record intended. There are many other things you can do when you've got a SQL injection point like this, but this isn't about SQL injection it's about how Evaluate() creates problems.

In ColdFusion, any variable in a CFQUERY block that is wrapped in single quotes ('#variables.string#') will be automatically escaped. In other languages like PHP you have to do this maually, but CF does it automatically. Escaping these strings prevents malicious users from injecting SQL commands into the query. It makes the database treat the string as just a string and not as a series of commands that's part of the SQL statement.

If you were to run this script on a CF server you would discover that the string in variables.hack is NOT escaped. This allows SQL to be injected into the query. Why is this? The Evaluate() statement is wrapped in single quotes, so what gives?

Well.. actually, ColdFusion is working as intended. There are several passes of the SQL statement made by ColdFusion. The first pass handles the escaping of variables. The second pass handles executing functions and after that the SQL is passed on to the database. If you had something like:

<cfset variables.msg="hack'd">
<cfquery datasource="misc" name="test">
  SELECT *
  FROM Test
  WHERE Name = '#Evaluate( "variables.#msg#" )#'
</cfquery>

You would find the Evaluate() statement becomes:
Evaluate( "variables.hack''d" )

Two single-quotes is the escape sequence for a single quot e in SQL. The contents of the msg variable are escaped. After this escape, Evaluate() is executed. In this case it'd return an error since variable names can't contain single-quotes.

So you see, the escaping of variables occurs before Evaluate() is processed. This means the contents of whatever Evaluate() will not be escaped and provides a point of injection for an attacker.

The solution is to set the results of the Evaluate() call to a temp variable and use that temp variable inside the CFQUERY.

<cfset variables.test = Evaluate( "variables.hack" )>
<cfquery datasource="misc" name="test">
  SELECT *
  FROM Test
  WHERE Name = '#variables.test#'
</cfquery>

Where is this used in the real world? Arrays. Something where you loop through a number set, say 1 to 20, where you insert the Nth value in an array into the database. Something like SET data = '#Evaluate( "userdata[#X#]" )#' where userdata is an array that stores data provided by the user (form data, data pulled from a database that was set through another application, etc.)

This problem exists for other functions used in a CFQUERY.

That is, any function that performs an evaluation of a string will have the same problem. IIF() is one such function. I'm not sure what others there are off the top of my head, but it's definately something to think about.

So the point to remember is to never pass any data that, at any time could be set by the user, through Evaluate() and IIF().

And there you go. A couple exploit vectors (as the security guys say) in ColdFusion that you need to be aware of if you're a CF developer.