Applebees Fail.



  •  Got this while filling out a job application at applebees.Applebees Fail

     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>&nbsp;Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.272&nbsp;
    
            </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.



  • [AWS Expiry Error]

    TRWTF is you not knowing that AWS-hosted images change URLs frequently to avoid hotlinking like you're trying to do.



  • @Manni_reloaded said:

    @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.

    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.

    @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.


  • Trolleybus Mechanic

    @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:

    @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!

    Ah, that's a good point. 

    @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.


  • Considered Harmful

    @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

     


Log in to reply