Hello end user! Just FYI, the admin password to this database is: xyz

February 16, 2009 11:34 AM

What might cause a SQLOLEDB connection string (containing an admin username/password) to briefly appear on-screen in a browser session and would I be crazy to buy a product that's had this bug for who knows how long without realizing it?

I'm evaluating an expensive, best-of-breed piece of software (seriously, you'd be shocked! shocked! to hear who it is) with a major web-based component...when end users log in, there's a brief flicker on-screen wherein the full database connection string is visible, in all its MSSQL-authentication-password-in-clear-text (with db_owner privileges) glory.

Apparently this has gone unnoticed for quite some time and the company has reproduced the issue (they see the brief flickering of text), but can't figure out what's causing it, and is trying to enlist my help in resolving it by WebExing into my machine (even though they can reproduce it from their environment).

Their current challenge is that they can't press the printscreen key at the right moment to actually capture the text and verify that the problem is in fact real, which took me all of one minute to figure out (I guess you need the rhythm of an improvisational keyboard player or somethin').

The web component is mostly built in ASP Classic, mostly VB, though I'm seeing some JScript here and there. I'd rather not dig through all of their code myself, which is not my responsibility, but I thought this would be a good question for the Hive Mind to chew on -- what could cause this, and should I be doing business with this company?

I'm also put off by using a db_owner account for simple end user activity, and the lack of Windows authentication (from a SQL standpoint -- the app does support Windows authentication for logging in), though it seems way-too-many off-the-shelf-products tend to do this, and in our pursuit for software built on best practices, we are constantly disappointed and our options are always so narrow.

I'm pretty familiar with ASP but not so much with JScript. I could see how a developer would Response.Write a connection string for debugging purposes, but can't imagine how this would go unnoticed for so long in a major commercial application.

Can you think of any other trigger that would cause the connection string to appear, other than the developer specifically saying "print the damn thing on-screen?"

More specifically, what appears on-screen is:


$DOMAIN\Username$ [populated with real information, of course]
SQLOLEDB Connection String
C:\Program Files\Path\To\Application\Server\Folder


Sure looks like debug code, eh?

posted by aydeejones to computers & internet (8 comments total)

My first guess would be debug code, but it's not necessary printf style debugging (i.e., using print or echo statements to spit out info). I'm no longer very familiar ASP classic, but PHP has a similar bugaboo, namely that when the PHP executable is configured to print certain runtime debug information, it'll print it right to the output stream, inserting it into your webpage. Perhaps the issue is a debug/logging setting for the entire package.

And no, I wouldn't use a piece of software like that until I knew damn well where it came from.
posted by fatbird at 11:44 AM on February 16

My classic ASP skills are super rusty, but I don't remember anything that would let you print something to the screen for a second before disappearing it. Is there JScript making it disappear, then? And if so, does the original text still show up somewhere if you view the source for the page once it fully loads? I would hope they would have noticed that by now, but sometimes people forget to check the obvious stuff.
posted by vytae at 11:51 AM on February 16

fatbird: that's kind of what I was thinking; perhaps there's a configuration switch of sorts that is simply causing this information to be dumped to the output stream.

It's tricky to see what's going on unless you're used to seeing connection strings on a regular basis and are desperately looking for hidden flaws in a pricey product before you've purchased it and earned the ire of your peers for strongly leaning towards the product, which happens to be the case for me. I really do want it to work out, and this really is a huge player in the market that hits on all of the points in our requirements list. But I told them right out, the fact that this bug exists at all makes me question their entire approach to security.

And, they initially say the whole product is built on .NET and C++, yet we're dealing with oodles of ASP classic for the web piece...which of course they will not support if you decide to customize it.

vytae: This occurs during a refresh/redirect of sorts...so it just flickers on the screen for a split-second when you log into the helpdesk via NT authentication, and then you're redirected to your own, logged-in page. At that point it's too late to view source, though I could probably try to find out if it's being cached.

Everyone: another flaw is that the entire IIS folder containing all of this ASP code must be opened up to "Domain Users" with MODIFY privileges, rather than just targeting specific config files, etc. I realize end users can't easily alter this data since it's not being shared via SMB, but it seems pretty goofy to design the product this way, rather than specifically documenting which folders / files require modify privileges (and providing easy scripts to deploy, and keeping this segregation in mind all along while building the folder structure for IIS). I took a stab at locking things down, and then granting modify privileges on files that were obviously being modified when an end user uses the product (config files, session information), but I was not comprehensive enough in my approach and this broke the entire [demo] install.

Sheesh.

Caring about security is hard. Waah!
posted by aydeejones at 12:13 PM on February 16

Heh, I just revealed what type of product this is. Silly me. I'm not trying to be stunt-posty, I swear, but I'll leave that in. My heart actually sank for a second, then I figured, so what?
posted by aydeejones at 12:14 PM on February 16

Use a tool like Wireshark or Fiddler2 to see what's actually being passed over the wire. This will let you capture the URLs as well, and you can read the ASP scripts to see what's being invoked along the way. I'm not aware of any generic ASP setting that outputs stuff like that, but if there is one I suppose it'd be in global.asa.

In my experience, the vast majority of "enterprise" business software is crap. Crap, crap, crap. Your goal, I suppose, is to find the least crappy product. A flaw like this in the product wouldn't surprise me one bit.

Most of these products also don't come with decent lockdown settings, and don't provide any support for locking down the system beyond what they tell you to do. That said, you can use a tool like Filemon to see what files are being accessed and how they're being accessed, and perhaps lock down most of your web root to read-execute.

Good luck!
posted by me & my monkey at 12:39 PM on February 16

another flaw is that the entire IIS folder containing all of this ASP code must be opened up to "Domain Users" with MODIFY privileges, rather than just targeting specific config files, etc. I realize end users can't easily alter this data since it's not being shared via SMB

Well... actually, unless you've specifically DISabled the administrative share for the drive on which the folder is located, an end user with sufficient clue _could_ access the folder via SMB... eg: "\\brokenIIS\c$\www\totallybustedhelpdeskappohmy"
posted by coriolisdave at 2:18 PM on February 16

For the "can't hit print screen quick enough" issue - you could try CamStudio. That records screen activity as an AVI, and can also convert it into an SWF video.
posted by Electric Dragon at 2:26 PM on February 16

me & my monkey: great suggestions and reassurring, to boot. I honestly didn't want to put too much legwork into this and was curious whether it was likely to be an outright coding mistake, or a more simple configuration issue.

And, I'm very appreciative of perspectives on the relative flimsiness of enterprise software, because it's a real nightmare to make an informed purchasing decision with lots of other peoples' money, though it's important to remember that the perfect is the enemy of the good.

coriolisdave: nope, the cluefulness of the sysadmin is the most important factor there:

Our end users are "Domain Users" and do not belong to any local admin groups on any workstations or servers; the "Domain Users" only resides in the local [limited] "Users" group on each machine per group policy. As such they cannot access administrative shares. An attempt to do so just brings up an authentication dialog.

Electric Dragon: I recommended that, and they had no luck. Maybe they didn't really try.

As it turns out, this was caused by debug code, and a fix has been written (commenting out the code, heh).
posted by aydeejones at 3:15 PM on February 16