Definately. I'm mostly going against the tone of the article and the comments below it. Its just all an awfully worded mess. The article didn't mention any of that, just the SQL injection. _NOW_ its been updated, and at the bottom of the article you see something along the line of "There's nothing about this attack that has to do with the technology, just poorly written asp and asp.net apps", which makes the article far closer to reality. But originaly, it wasn't quite so.
Indeed. As I replied already however to another post, Transact-SQL is actually not just Sybase or MS SQL server specific, a couple of other (albeit more obscure) DBMS and compatibility layers that are semi-common allow for it too. Now, if it uses MS SQL specific features, such as the default system SPs, is something else.
Also, this ends up being an applicative attack. This is no more an SQL Server hack than a buffer overflow attack is a C/C++ one, which was my secondary point. What was hacked was the particular web applications which had severe programming/design flaws in them. The attack isn't aimed at Microsoft: its aimed at stupid MS centric developers (and even that is debatable, reading more into it the attack had many more vectors than just the sql one). Microsoft's server design (or lack of, depending on which side you are) had nothing to do with the attack.
Its a bit like if someone was going around using unsecured Linksys router based wifi to trade kiddy porn, and in the news you'd see "Linksys routers hacked!!!", or that there was a worm in the wild that would own Linux distros that don't have root passwords and you saw "Linux has been hacked!". Its simply not the server software that has been hacked, its the applications that ran on them.
Yeah, because SQL Server is always used behind IIS...? (Also, Transact-SQL and compatible syntaxes are used in many other RDBMS, such as PervasiveSQL... now if they used SQL Server specific features, thats very possible and even likely, but again: doesn't have anything to do with IIS).
They are because they have execution plan and do not need to be parsed, syntax cheched etc...
See? Exactly what I was talking about. The execution plan is done on the fly as needed (not when the stored procedure is created), the syntax checking is only partly done at creation time (and is totally redone at runtime), and inline prepared statements all benefit from the exact same process. There is no difference. Most mainstream RDBMSs work like that (I do not know about the like of MySQL however). The only difference really, is the amount of data moving on the network, if the SQL query is extremely large.
Even DBAs seem to miss that, but it is well documented, and easy to benchmark. There is no difference between how compilation/execution plan/caching/parsing/checking/blahblahblah is done between an SP and a prepared statement. It is done the first time the query or the SP is -executed-, and its cached for all later executions as long as the only difference between queries is the filters (where clause, etc) and some other minor differences.
Doesn't change that IIS doesn't have anything to do with it. If you take aside that both ASP and ASP.NET (more ASP though) aren't IIS specific by a long shot, the attack is targeting specific technologies, then targetting specific software development flaws within the boundaries of those technologies. If I'm running PERL/PHP on my server, it won't see it. If I'm running an ASP page on Apache, it will, and even if my server hasn't been patched for the last 5 years, I'm no more or less vulnerable to that attack.
If the attackers looked for servers that were advertising themselves as IIS, and/or attacked IIS vulnerabilities or bad administration practices, you'd have a point. But the fact that the servers were running IIS was little beyond a strong corelation.
I don't know, personally. You need all those concat symbols, the parameters aren't obvious...
"select * from blah where stuff = " + var1 + " and lol = '" + var2 + "';";
It gets messy when you have strings, dates in special formats, xml literals, multiline queries... look at this around var2, the single quote followed by a double quote... messy messy. And depending on the language, you have to escape the quotes, etc. Crazy. How can you guys even read that? Nevermind debug it when it gets complicated.
Then when you need to modify the query, you need to start goofing around, moving the quotes, if it was a string that became a number, you have to change it (so you have to be "type aware"). It definately is far more time consuming in anything beyond a one shot web site made by a single developer that you won't maintain.
Though if you use a database driver that force you to use "?" as placeholders, its not quite as great as I make it (such as OLE DB), but modern ones that have named place holders ("@parameterName"), definately.
First, as someone already stated, the vulnerabilty is in poor software development practice, and is pervasive in all environments, be in MS, Linux, Apache, IIS, PHP, ASP.NET, JAVA, whatever.
Second, IIS, since version 6, is amazingly secure, comparable with the likes of Apache. Its also the more straightforward platform to use as an ASP.NET server (obviously, unless you're into Mono), or to use along with a lot of fairly interesting technologies, such as TFS, Reporting Services, Sharepoints, etc.
On top of that, well, just by having a windows-based network, IIS is already "pre-configured". That is, aside for web server specific stuff, its already on your server, can be admin-ed the same way, etc. Adding a box with a different OS, a non-integrated web server, etc, is just overhead.
Same way as regardless of anything, if you were all java based, NOT using a java app server for your web apps would just be overhead, unless you have a damn good reasons.
How can you blame them however? Look at what THIS site (as in Slashdot) is doing. The headline implies that its an IIS hack. If you read the posts attached to this -very- article, a significant amount of people are replying acting like it IS a server issue, related to MS or some such.
When such misconceptions are so pervasive (even in -articles- on a geek web site like here!), obviously newbies are going to be confused all over the place.
Its a bit similar on how there's still so many SQL Server DBAs who think stored procedures are faster by design than dynamic SQL.
No, i'm not trolling. My point is that the story itself is trolling. This isn't an IIS directed attack, it is a "bad programming" directed attack. The -same- attack, exactly, would work -regardless- of the server. You don't even need to CHECK which server is running on the machine for this attack to work, since the server is IRRELEVENT, and I was trying to demonstrate that. Nothing more.
It is NOT an IIS directed attack. At best, its a loose corelation statistic, and one thats pretty useless without comparing it to other references, such as other web servers.
I'd personally laugh at you. Escaping sql strings, what the hell? the 1980/90s called and they want their obsolete methodologies back.
In any semi-advanced programming language or framework (including PHP, even more so since PHP5 as it doesn't require any extension or whatever), you just use prepared statements. Maybe that MS SQL Server admin was a bozo, but in VB, you'll almost always be using prepared statements (even in VB5-6, pre-.NET), or at worse, stored procedures, which act as prepared statements.
SQL string escaping is inexistant in environments where prepared statements are first class citizens of the language/framework, because they're inferior methods of handling it. (and again: even in PHP its not what you're supposed to do).
You don't even need to sanitize database input. Just use freagin prepared statements. There's no cleanup or validation necessary (for this particular vulnerability I mean, that is, sql injection).
Yup. Heck, even if you are using SQL on every last thing... if you're using prepared statements (or stored procedures), which MUST be done for performance reasons and code maintainability ANYWAY (sql strings concat is such a rediculous anti-pattern...), you're immune.
SQL Injection is by far the stupidest security vulnerability there is... Worse than buffer overflows, cross site scripting, etc... Because you have to go -out of your way- to make them possible. You have to make your code slower, take more time to develop, harder to read and maintain, etc, before you can be vulnerable... You have to -try- (or be a totally clueless developer).
I agree, and that was my first reaction: "Wtf does IIS have to do with SQL injection". If nothing else, a LAMP stack would be more susceptible, not because of the servers, but because PHP didn't have mainstream prepared statements as part of a default standard install in its earlier versions, and now that it DOES have it, a lot of script kiddies or peanut gallery programmers aren't using them, as opposed to Java/.NET/Whatever which, while still having some issues with the same group of newbie developers, are prepared-statement centric in their development paradigms and documentation, thus reducing the amount of possible SQL injection significantly, unless the apps are made in legacy environments too.
Its such a rediculous flamebait, I don't know what to say.
Windows requires reboots for kernel level patches, but it sure as hell doesn't (even pre-Vista, it really didn't change in Vista) requires a reboot for even the most trivial of changes or update either.
The only reason someone may think so is because installers have a "You must reboot now" screen added to them by default and no one seems to remember to take em out. Kernel patches aside, its -extremely- rare to have to reboot a Windows machine. Virtually on the same level as a *nix box.
I have news for you however. Statistically and historically, CS-related work was mostly a big trail of failures. Virtually no project, aside a select few with insane ressources backing em, and a couple of lucky shots, actually ended up giving out more value than they required.
In this day and age, maybe its inefficient, maybe its not quite CS, maybe its not "cool", but it gets the job done, it saves money, it makes things work, its enabling. Its still not good enough in its current state, but its going in the right direction. We're leaving the "how" behind, and changing it with the "what". People have ideas, and they make those ideas a reality, and it "works".
It may not be as badass to implement an enterprise management system, as opposed to the first ethernet network, but you don't spend 3 years on a project to be left empty ended 90% of the time either.
No, unfortunately. They're being unclear, and it feels like its deliberate (though I wouldnt' make an actual accusation).
Its mostly just a very imaged explaination of their terms, but by looking at the devs comments in the forums, they're fairly clear: "We feel like anytime you use our stuff, you need to give back, either by giving us cash by paying for a license, or by releasing under an open source license your stuff, in our case, the GPL3"
The wording is really a mess, but when they say "an open source license", they are -refering- to the GPL3, not saying you can go out with any open source license.
Indeed, and it used to be dual licensed LGPL and commercial license. Now they replaced LGPL with GPL, because "The LGPL is not open source friendly". The hell? If LGPL isn't... then Apache, MIT, BSD...none of those are.
If I remember well, if an LGPL librairy is modified (that is, the librairy itself), yuo have to give back your changes to the community. The only difference with the GPL (well, the interesting difference in this case I mean), is that the non-ExtJS related code has to be given back too.
Oh yes! ExtJS developers seriously benefit from having access to my internal business logic! Now they can take my investment portfolio management code and add it as a main feature of ExtJS! How useful/sarcasm.
If all they wanted was to get back the improvements to ExtJS itself that third parties would have made, LGPL did that just fine.
Don't forget encryption to boot! Compressed + Encrypted (hey, its pay-for televison, no free ride by random inferior species!) = even more random-noise like.
Notice that I did not use the terminology to compate commercial and open source. The only time I used the commercial terminology was when refering to their dual licensing scheme, which is the way THEY (the ExtJS team) put it when discussing it.
Wrong or not, when refering to a product, I have to use that product's terminology, else there will be confusing when checking my statements against the reference.
On top of what everyone said already, there's also the (if I remember well) clause about distributing the source in a format that can be reused. So you can't just tell people "Well, my JS is open source, so you can just wget the source if you want it".
Also, certain projects like EXT GWT use ExtJS and "link" to it on the server side. Big issue here if you were trying to be closed source. At least they still offer a commercial license, but I feel like its very very "bait and switch"-ish tactic, ala big commercial entity.
This leaves a bad taste in my mouth about that project. And I don't know enough people with the kind of skills to fork the previous version...
Disclaimer: I'm far from an open source zealot, and while I've been 100% free software based for years, I'm currently 90% commercial software, both at home (which I personally paid for every single bit, not a single pirated software) and at work.
Seriously... thats silly. Open Source just diversify the market. Instead of SQL Server and Oracle saturating the market with a poorly suited solution, you have PostgreSQL and MySQL (and more) catering to a segment of the market which doesn't require SQL Server and Oracle, and let the big names (I use those 2, there's more) commercial ones fill up the rest of the market, or force them to add more value (for example, ETL, Datawarehouseing, etc) by making basic feature a commodity (if all you need is flat tables to run SQL on, you don't need Oracle).
So really, Free Software isn't taking money from anyone... they just force market expension. If free databases didn't exist, the commercial databases would have less features than now, and going after a smaller niche, to sell probably exactly the same amount of licenses as they are selling now.
Yeah. And the issue you've seen come from all the people (you see a lot of them in the comments) who beleive that making a site accessible is just a matter of following the check lists that are going around... "Its easy! make your site XHTML compliant, use CSS for layout, and use alt text for images and voila!!"
When in reality, you need carefully thought up (hidden) links and anchors to allow screen readers to smartly navigate around and skip things they don't care about, you need groups and access keys all over, and all around a bunch of things that aren't necessarly semantic (a big one) and definately not visible. So its like making a full web site, and 1/4th of another one, to some extent. Groups and legends have rediculous defaults in most browsers, so you have to spend time styling them correctly or hiding them, too.
Making a site accessible, and making it -usuable- by people with disabilities, is seriously two things. (Also, screen readers are only one part of the equation... you also have to make it easy to navigate without a mouse for people with other types of disabilities, which may sometime even conflict with screen reader usuability... then people who are colorblind, and thats a HUGE chunk of people...and more!).
Its pretty tough to think about everything... Heck, it isn't that easy to make a good site design for -normal- people in the first place.
I saw a software once, though I lost it, that would display (visually) a web site the way a screen reader would see it. So tables would be flattened, CSS mostly ignored, no color, no images, etc. That helped a lot and was quite enlightening...though it was a long time ago and was pretty obscure.
and I agree with you. We have all these javascript debuggers and profilers, stuff like firebug, Opera's built in way of displaying page constructs...we even have "accessibility validators", and a bunch of base guidelines... but that still feels like making accessible web pages is like programming without a debugger. A leap of faith.
Without easily accessible "developer edition" of these screen readers, and various similar tools, its hopeless. It all becomes a theory vs practice game.
Slashdot Mirror
Sorry, no offence, but did you read my post fully? It wasn't that long :) I specifically said that my comment only talked about SQL Injection.
Definately. I'm mostly going against the tone of the article and the comments below it. Its just all an awfully worded mess. The article didn't mention any of that, just the SQL injection. _NOW_ its been updated, and at the bottom of the article you see something along the line of "There's nothing about this attack that has to do with the technology, just poorly written asp and asp.net apps", which makes the article far closer to reality. But originaly, it wasn't quite so.
Indeed. As I replied already however to another post, Transact-SQL is actually not just Sybase or MS SQL server specific, a couple of other (albeit more obscure) DBMS and compatibility layers that are semi-common allow for it too. Now, if it uses MS SQL specific features, such as the default system SPs, is something else.
Also, this ends up being an applicative attack. This is no more an SQL Server hack than a buffer overflow attack is a C/C++ one, which was my secondary point. What was hacked was the particular web applications which had severe programming/design flaws in them. The attack isn't aimed at Microsoft: its aimed at stupid MS centric developers (and even that is debatable, reading more into it the attack had many more vectors than just the sql one). Microsoft's server design (or lack of, depending on which side you are) had nothing to do with the attack.
Its a bit like if someone was going around using unsecured Linksys router based wifi to trade kiddy porn, and in the news you'd see "Linksys routers hacked!!!", or that there was a worm in the wild that would own Linux distros that don't have root passwords and you saw "Linux has been hacked!". Its simply not the server software that has been hacked, its the applications that ran on them.
Yeah, because SQL Server is always used behind IIS...? (Also, Transact-SQL and compatible syntaxes are used in many other RDBMS, such as PervasiveSQL... now if they used SQL Server specific features, thats very possible and even likely, but again: doesn't have anything to do with IIS).
Even DBAs seem to miss that, but it is well documented, and easy to benchmark. There is no difference between how compilation/execution plan/caching/parsing/checking/blahblahblah is done between an SP and a prepared statement. It is done the first time the query or the SP is -executed-, and its cached for all later executions as long as the only difference between queries is the filters (where clause, etc) and some other minor differences.
Doesn't change that IIS doesn't have anything to do with it. If you take aside that both ASP and ASP.NET (more ASP though) aren't IIS specific by a long shot, the attack is targeting specific technologies, then targetting specific software development flaws within the boundaries of those technologies. If I'm running PERL/PHP on my server, it won't see it. If I'm running an ASP page on Apache, it will, and even if my server hasn't been patched for the last 5 years, I'm no more or less vulnerable to that attack.
If the attackers looked for servers that were advertising themselves as IIS, and/or attacked IIS vulnerabilities or bad administration practices, you'd have a point. But the fact that the servers were running IIS was little beyond a strong corelation.
I don't know, personally. You need all those concat symbols, the parameters aren't obvious...
"select * from blah where stuff = " + var1 + " and lol = '" + var2 + "';";
It gets messy when you have strings, dates in special formats, xml literals, multiline queries... look at this around var2, the single quote followed by a double quote... messy messy. And depending on the language, you have to escape the quotes, etc. Crazy. How can you guys even read that? Nevermind debug it when it gets complicated.
Then when you need to modify the query, you need to start goofing around, moving the quotes, if it was a string that became a number, you have to change it (so you have to be "type aware"). It definately is far more time consuming in anything beyond a one shot web site made by a single developer that you won't maintain.
Though if you use a database driver that force you to use "?" as placeholders, its not quite as great as I make it (such as OLE DB), but modern ones that have named place holders ("@parameterName"), definately.
First, as someone already stated, the vulnerabilty is in poor software development practice, and is pervasive in all environments, be in MS, Linux, Apache, IIS, PHP, ASP.NET, JAVA, whatever.
Second, IIS, since version 6, is amazingly secure, comparable with the likes of Apache. Its also the more straightforward platform to use as an ASP.NET server (obviously, unless you're into Mono), or to use along with a lot of fairly interesting technologies, such as TFS, Reporting Services, Sharepoints, etc.
On top of that, well, just by having a windows-based network, IIS is already "pre-configured". That is, aside for web server specific stuff, its already on your server, can be admin-ed the same way, etc. Adding a box with a different OS, a non-integrated web server, etc, is just overhead.
Same way as regardless of anything, if you were all java based, NOT using a java app server for your web apps would just be overhead, unless you have a damn good reasons.
How can you blame them however? Look at what THIS site (as in Slashdot) is doing. The headline implies that its an IIS hack. If you read the posts attached to this -very- article, a significant amount of people are replying acting like it IS a server issue, related to MS or some such.
When such misconceptions are so pervasive (even in -articles- on a geek web site like here!), obviously newbies are going to be confused all over the place.
Its a bit similar on how there's still so many SQL Server DBAs who think stored procedures are faster by design than dynamic SQL.
No, i'm not trolling. My point is that the story itself is trolling. This isn't an IIS directed attack, it is a "bad programming" directed attack. The -same- attack, exactly, would work -regardless- of the server. You don't even need to CHECK which server is running on the machine for this attack to work, since the server is IRRELEVENT, and I was trying to demonstrate that. Nothing more.
It is NOT an IIS directed attack. At best, its a loose corelation statistic, and one thats pretty useless without comparing it to other references, such as other web servers.
I'd personally laugh at you. Escaping sql strings, what the hell? the 1980/90s called and they want their obsolete methodologies back.
In any semi-advanced programming language or framework (including PHP, even more so since PHP5 as it doesn't require any extension or whatever), you just use prepared statements. Maybe that MS SQL Server admin was a bozo, but in VB, you'll almost always be using prepared statements (even in VB5-6, pre-.NET), or at worse, stored procedures, which act as prepared statements.
SQL string escaping is inexistant in environments where prepared statements are first class citizens of the language/framework, because they're inferior methods of handling it. (and again: even in PHP its not what you're supposed to do).
You don't even need to sanitize database input. Just use freagin prepared statements. There's no cleanup or validation necessary (for this particular vulnerability I mean, that is, sql injection).
Yup. Heck, even if you are using SQL on every last thing... if you're using prepared statements (or stored procedures), which MUST be done for performance reasons and code maintainability ANYWAY (sql strings concat is such a rediculous anti-pattern...), you're immune.
SQL Injection is by far the stupidest security vulnerability there is... Worse than buffer overflows, cross site scripting, etc... Because you have to go -out of your way- to make them possible. You have to make your code slower, take more time to develop, harder to read and maintain, etc, before you can be vulnerable... You have to -try- (or be a totally clueless developer).
There is no excuse for it.
I agree, and that was my first reaction: "Wtf does IIS have to do with SQL injection". If nothing else, a LAMP stack would be more susceptible, not because of the servers, but because PHP didn't have mainstream prepared statements as part of a default standard install in its earlier versions, and now that it DOES have it, a lot of script kiddies or peanut gallery programmers aren't using them, as opposed to Java/.NET/Whatever which, while still having some issues with the same group of newbie developers, are prepared-statement centric in their development paradigms and documentation, thus reducing the amount of possible SQL injection significantly, unless the apps are made in legacy environments too.
Its such a rediculous flamebait, I don't know what to say.
Windows requires reboots for kernel level patches, but it sure as hell doesn't (even pre-Vista, it really didn't change in Vista) requires a reboot for even the most trivial of changes or update either.
The only reason someone may think so is because installers have a "You must reboot now" screen added to them by default and no one seems to remember to take em out. Kernel patches aside, its -extremely- rare to have to reboot a Windows machine. Virtually on the same level as a *nix box.
I have news for you however. Statistically and historically, CS-related work was mostly a big trail of failures. Virtually no project, aside a select few with insane ressources backing em, and a couple of lucky shots, actually ended up giving out more value than they required.
In this day and age, maybe its inefficient, maybe its not quite CS, maybe its not "cool", but it gets the job done, it saves money, it makes things work, its enabling. Its still not good enough in its current state, but its going in the right direction. We're leaving the "how" behind, and changing it with the "what". People have ideas, and they make those ideas a reality, and it "works".
It may not be as badass to implement an enterprise management system, as opposed to the first ethernet network, but you don't spend 3 years on a project to be left empty ended 90% of the time either.
No, unfortunately. They're being unclear, and it feels like its deliberate (though I wouldnt' make an actual accusation).
Its mostly just a very imaged explaination of their terms, but by looking at the devs comments in the forums, they're fairly clear: "We feel like anytime you use our stuff, you need to give back, either by giving us cash by paying for a license, or by releasing under an open source license your stuff, in our case, the GPL3"
The wording is really a mess, but when they say "an open source license", they are -refering- to the GPL3, not saying you can go out with any open source license.
Indeed, and it used to be dual licensed LGPL and commercial license. Now they replaced LGPL with GPL, because "The LGPL is not open source friendly". The hell? If LGPL isn't... then Apache, MIT, BSD...none of those are.
If I remember well, if an LGPL librairy is modified (that is, the librairy itself), yuo have to give back your changes to the community. The only difference with the GPL (well, the interesting difference in this case I mean), is that the non-ExtJS related code has to be given back too.
/sarcasm.
Oh yes! ExtJS developers seriously benefit from having access to my internal business logic! Now they can take my investment portfolio management code and add it as a main feature of ExtJS! How useful
If all they wanted was to get back the improvements to ExtJS itself that third parties would have made, LGPL did that just fine.
Don't forget encryption to boot! Compressed + Encrypted (hey, its pay-for televison, no free ride by random inferior species!) = even more random-noise like.
Notice that I did not use the terminology to compate commercial and open source. The only time I used the commercial terminology was when refering to their dual licensing scheme, which is the way THEY (the ExtJS team) put it when discussing it.
Wrong or not, when refering to a product, I have to use that product's terminology, else there will be confusing when checking my statements against the reference.
On top of what everyone said already, there's also the (if I remember well) clause about distributing the source in a format that can be reused. So you can't just tell people "Well, my JS is open source, so you can just wget the source if you want it".
Also, certain projects like EXT GWT use ExtJS and "link" to it on the server side. Big issue here if you were trying to be closed source. At least they still offer a commercial license, but I feel like its very very "bait and switch"-ish tactic, ala big commercial entity.
This leaves a bad taste in my mouth about that project. And I don't know enough people with the kind of skills to fork the previous version...
Disclaimer: I'm far from an open source zealot, and while I've been 100% free software based for years, I'm currently 90% commercial software, both at home (which I personally paid for every single bit, not a single pirated software) and at work.
Seriously... thats silly. Open Source just diversify the market. Instead of SQL Server and Oracle saturating the market with a poorly suited solution, you have PostgreSQL and MySQL (and more) catering to a segment of the market which doesn't require SQL Server and Oracle, and let the big names (I use those 2, there's more) commercial ones fill up the rest of the market, or force them to add more value (for example, ETL, Datawarehouseing, etc) by making basic feature a commodity (if all you need is flat tables to run SQL on, you don't need Oracle).
So really, Free Software isn't taking money from anyone... they just force market expension. If free databases didn't exist, the commercial databases would have less features than now, and going after a smaller niche, to sell probably exactly the same amount of licenses as they are selling now.
Yeah. And the issue you've seen come from all the people (you see a lot of them in the comments) who beleive that making a site accessible is just a matter of following the check lists that are going around... "Its easy! make your site XHTML compliant, use CSS for layout, and use alt text for images and voila!!"
When in reality, you need carefully thought up (hidden) links and anchors to allow screen readers to smartly navigate around and skip things they don't care about, you need groups and access keys all over, and all around a bunch of things that aren't necessarly semantic (a big one) and definately not visible. So its like making a full web site, and 1/4th of another one, to some extent. Groups and legends have rediculous defaults in most browsers, so you have to spend time styling them correctly or hiding them, too.
Making a site accessible, and making it -usuable- by people with disabilities, is seriously two things. (Also, screen readers are only one part of the equation... you also have to make it easy to navigate without a mouse for people with other types of disabilities, which may sometime even conflict with screen reader usuability... then people who are colorblind, and thats a HUGE chunk of people...and more!).
Its pretty tough to think about everything... Heck, it isn't that easy to make a good site design for -normal- people in the first place.
I saw a software once, though I lost it, that would display (visually) a web site the way a screen reader would see it. So tables would be flattened, CSS mostly ignored, no color, no images, etc. That helped a lot and was quite enlightening...though it was a long time ago and was pretty obscure.
and I agree with you. We have all these javascript debuggers and profilers, stuff like firebug, Opera's built in way of displaying page constructs...we even have "accessibility validators", and a bunch of base guidelines... but that still feels like making accessible web pages is like programming without a debugger. A leap of faith.
Without easily accessible "developer edition" of these screen readers, and various similar tools, its hopeless. It all becomes a theory vs practice game.