Applebees Fail.
-
Got this while filling out a job application at applebees.
Just to clarify, here's the full code below.
Server Error in '/' Application.
<h2> <i>String or binary data would be truncated.<br>The statement has been terminated.</i> </h2> <font face="Arial, Helvetica, Geneva, SunSans-Regular, sans-serif "> <b> Description: </b>An unhandled exception occurred during
the execution of the current web request. Please review the stack trace
for more information about the error and where it originated in the
code.<br><br> <b> Exception Details: </b>System.Data.SqlClient.SqlException: String or binary data would be truncated.<br>The statement has been terminated.<br><br> <b>Source Error:</b> <br><br> <table bgcolor="#ffffcc" width="100%"> <tbody><tr> <td> <code>
An unhandled exception was generated during the execution of the current
web request. Information regarding the origin and location of the
exception can be identified using the exception stack trace below.</td> </tr> </tbody></table> <br> <b>Stack Trace:</b> <br><br> <table bgcolor="#ffffcc" width="100%"> <tbody><tr> <td> <code><pre>[SqlException (0x80131904): String or binary data would be truncated.
The statement has been terminated.]
System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection) +404
System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning() +412
System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj) +1363
System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString) +6387805
System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async) +6389506
System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result) +538
System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe) +689
System.Data.SqlClient.SqlCommand.ExecuteNonQuery() +327
Microsoft.Practices.EnterpriseLibrary.Data.Database.DoExecuteNonQuery(DBCommandWrapper command) +394
Microsoft.Practices.EnterpriseLibrary.Data.Database.ExecuteNonQuery(DBCommandWrapper command) +104
AppleBees.JobHistory.Save(Int32 orderID) in D:\Work\Applebees\Applebees 2.0\trunk\development\legacy-applebees\Legacy Applebees\WorkWithUs\JobHistory.ascx.vb:112
AppleBees.Application3.cmdNext_Click(Object sender, ImageClickEventArgs e) in D:\Work\Applebees\Applebees 2.0\trunk\development\legacy-applebees\Legacy Applebees\WorkWithUs\Application3.aspx.vb:48
System.Web.UI.WebControls.ImageButton.OnClick(ImageClickEventArgs e) +187
System.Web.UI.WebControls.ImageButton.RaisePostBackEvent(String eventArgument) +165
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +3707
</td> </tr> </tbody></table> <br> <hr color="silver" size="1" width="100%"> <b>Version Information:</b> Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.272 </font><p></p><p>Among the WTFs I can see is an unsanitized SQL call and it expecting to find stuff in a local path. <br></p><div id="swiffout"></div>
-
@Steeldragon said:
D:\Work\Applebees\Applebees 2.0\trunk\development\legacy-applebees\Legacy Applebees\WorkWithUs\JobHistory.ascx.vb
A directory path like that is telling enough...
-
Blown a field in the database would be my guess, but I haven't looked too closely...
-
The local path isn't a WTF.
In .NET, if you deploy a debug build, stack traces will include paths to the files as if they were on the developer's system who compiled it. I've deployed debug builds so I can log stack traces if someone is having an issue, and while c:\users\[my username]\documents\Visual Studio\projects\ doesn't exist on the server running the code, that's where it was when I compiled it, on my system, so it shows in the logs.
-
Applying for a job at Applebees is TRWTF.
-
@mott555 said:
The local path isn't a WTF.
It looks like they're having trouble with it. as you say, it's a debug build and they've turned customErrors off completely.
-
Who says the SQL is unsanitized? This error can happen even when the string is in SQL parameters...
-
@mott555 said:
The local path isn't a WTF.
Ok...
@mott555 said:
In .NET, if you deploy a debug build,
Deploying a debug build IS a WTF!
-
@Medinoc said:
Who says the SQL is unsanitized? This error can happen even when the string is in SQL parameters...
I think what he's saying is that there's no evidence of validation that the data submitted would match the data types/lengths of fields in the table. Even an ugly solution like putting that validation on the form itself would be a slight improvement to this. Or put the SQL call in a try/catch, y'know just in case something goes wrong.
Or I guess you could just cross your fingers and hope. The absence of any basic logic tells me you could probably inject something here pretty easily.
-
This doesn't have to be a debug build. You get the path if you deploy the .pdb files, with a release or debug build.
-
TRWTF is you not knowing that AWS-hosted images change URLs frequently to avoid hotlinking like you're trying to do.
-
@Manni_reloaded said:
Am I missing a (not funny) joke here? Try...catch won't protect against SQL injection. And putting validation in the form is only an "improvement" in the sense that a shit sandwich is an improvement on a shit and vomit sandwich.@Medinoc said:
Who says the SQL is unsanitized? This error can happen even when the string is in SQL parameters...
I think what he's saying is that there's no evidence of validation that the data submitted would match the data types/lengths of fields in the table. Even an ugly solution like putting that validation on the form itself would be a slight improvement to this. Or put the SQL call in a try/catch, y'know just in case something goes wrong.
@Manni_reloaded said:
Or I guess you could just cross your fingers and hope. The absence of any basic logic tells me you could probably inject something here pretty easily.
What "absence of any basic logic"? You have absolutely no idea what was done to the data before the point at which AppleBees.JobHistory.Save calls Microsoft.Practices.EnterpriseLibrary.Data.Database.ExecuteNonQuery. The only absence of logic appears to be in your reasoning.
-
It could still be worse. The stack could go straight from AppleBees.Application3.cmdNext_Click to System.Data.SqlClient.SqlCommand.ExecuteNonQuery.
-
@Cassidy said:
@Steeldragon said:
D:\Work\Applebees\Applebees 2.0\trunk\development\legacy-applebees\Legacy Applebees\WorkWithUs\JobHistory.ascx.vb
A directory path like that is telling enough...
I'm actually a wee bit impressed that despite all the other shenanigans going on, it looks like they're using source control.
Granted, the sequence "trunk\development\legacy" seems to imply that they're doing something screwy with it...but then, the company where I work is still attempting to recover from something similarly bewildering.
-
@kilroo said:
it looks like they're using source control.
Or the word "trunk" is there due to cargo cult-ism. Do not assume to much, padawan.
-
@DaveK said:
Am I missing a (not funny) joke here? Try...catch won't protect against SQL injection. And putting validation in the form is only an "improvement" in the sense that a shit sandwich is an improvement on a shit and vomit sandwich.
The try/catch won't prevent an injection. I think the point was that if they'd wrapped that query in a try/catch, they could have caught the string-too-fucking-long exception. And then, instead of dumping a stacktrace to a public-facing server, they could have put up a pretty error page with an apple and a suggestion that maybe he'd like some greasy overpriced grease-topped grease FOR FAMILY!
Form-validation: It's only marginally better in the sense that it would have prevent OP from seeing the error. Client-side validation is a convenience, and a good way to catch honest mistakes by honest people. Presumably the OP wasn't intentionally trying to inject 201 characters into a varchar(200) field. The OP PROBABLY wouldn't have seen the error.
-
@Lorne Kates said:
Ah, that's a good point.@DaveK said:
Am I missing a (not funny) joke here? Try...catch won't protect against SQL injection. And putting validation in the form is only an "improvement" in the sense that a shit sandwich is an improvement on a shit and vomit sandwich.
The try/catch won't prevent an injection. I think the point was that if they'd wrapped that query in a try/catch, they could have caught the string-too-fucking-long exception. And then, instead of dumping a stacktrace to a public-facing server, they could have put up a pretty error page with an apple and a suggestion that maybe he'd like some greasy overpriced grease-topped grease FOR FAMILY!
@Lorne Kates said:
Form-validation: It's only marginally better in the sense that it would have prevent OP from seeing the error. Client-side validation is a convenience, and a good way to catch honest mistakes by honest people. Presumably the OP wasn't intentionally trying to inject 201 characters into a varchar(200) field. The OP PROBABLY wouldn't have seen the error.
Well, you know, what I was thinking was that if you validate the length of the field to 200 chars on the client-side, and then escape it at the server-side, that could actually cause the problem by extending its length. You need to validate it after any sanitisation, not before.
-
@Lorne Kates said:
@DaveK said:
Am I missing a (not funny) joke here? Try...catch won't protect against SQL injection. And putting validation in the form is only an "improvement" in the sense that a shit sandwich is an improvement on a shit and vomit sandwich.
The try/catch won't prevent an injection. I think the point was that if they'd wrapped that query in a try/catch, they could have caught the string-too-fucking-long exception. And then, instead of dumping a stacktrace to a public-facing server, they could have put up a pretty error page with an apple and a suggestion that maybe he'd like some greasy overpriced grease-topped grease FOR FAMILY!
Form-validation: It's only marginally better in the sense that it would have prevent OP from seeing the error. Client-side validation is a convenience, and a good way to catch honest mistakes by honest people. Presumably the OP wasn't intentionally trying to inject 201 characters into a varchar(200) field. The OP PROBABLY wouldn't have seen the error.
Well fine, if you wanna say it all fancy-like.
-
@kilroo said:
Granted, the sequence "trunk\development\legacy" seems to imply that they're doing something screwy with it...
... like using development code on a production server - or they've just picked meaningless names for their dirs.
Similarly, there's something called "Legacy Applebees" in a dir called "legacy-applebees". I'm curious to know what else that dir contains.
-
@Cassidy said:
Similarly, there's something called "Legacy Applebees" in a dir called "legacy-applebees". I'm curious to know what else that dir contains.
Buffalo wings?
-
@Cassidy said:
Similarly, there's something called "Legacy Applebees" in a dir called "legacy-applebees". I'm curious to know what else that dir contains.
"Legacy Denny's." OH SHIT THE SECRET IS OUT!
-
TRWTF is, of course, having no custom error page and dumping errors on the remote. Security 101.
-
@Cassidy said:
@kilroo said:
Granted, the sequence "trunk\development\legacy" seems to imply that they're doing something screwy with it...
... like using development code on a production server - or they've just picked meaningless names for their dirs.
Similarly, there's something called "Legacy Applebees" in a dir called "legacy-applebees". I'm curious to know what else that dir contains.
I'm thinking:
Applebees Bad Applebees New Applebees Newer Applebees Newest-DO NOT USE Applebees Old Legacy Applebees
All of which are now considered "Legacy"
-
@joe.edwards said:
All of which are now considered "Legacy"
OLDSKOOOOL!
-
@Cassidy said:
Similarly, there's something called "Legacy Applebees" in a dir called "legacy-applebees". I'm curious to know what else that dir contains.
Legacy_Applebees, legacy-applebees-2, legacy-applebees-backup, legacy-applebees-bobs-fixed-version