The $30k Web App



  • Some time ago, a certain company outsourced a re-write of a site from  Java to .NET, and the word was to keep MVC, and that everything should be coded in C#. Of course, they dilligently did most of the site in VB.NET (first fail) and stuck all the Page_Load() code on the .aspx files (second fail). The login screens are smart enough to check for SQL injection attacks ... but the GET query strings did not (third fail). I actually was able to deface the dev site with a simple URL as a proof of concept, and to ask for a complete rewrite of this site. Note: This was the DEV site, not production site, and yes I backed up the database before this. The problem  has usually been that

    - The "site" cost something like $30k

    - They were still asking the original devs to update the thing.

    Of course, they haven't done anything in over a year, so "Project: Recode" has finally been greenlighted. While on the job, one of the new devs found this gem:

     <FONT color=#ff0000><asp:Button id="LoginButton" CssClass="button" runat="server" Text=":: Login ::" OnClick="srch_mail"/></asp:button>
    </FONT>



  • @danixdefcon5 said:

    Text=":: Login ::" OnClick="srch_mail"
    Clearly security through obscurity.



  • "srch_mail"? WTF? Does it log users in using an SMTP server as a backend?



  • @danixdefcon5 said:

    ...and stuck all the Page_Load() code on the .aspx files...
     

    @danixdefcon5 said:

    <asp:Button id="LoginButton"
    CssClass="button" runat="server" Text=":: Login ::"
    OnClick="srch_mail"/></asp:button>
     

    Care to explain either of these for those of us who don't know anything about .NET web development?



  • Of course not, it is clearly using POP3 instead.



  • @danixdefcon5 said:

    Some time ago, a certain company outsourced a re-write of a site from  Java to .NET, and the word was to keep MVC, and that everything should be coded in C#. Of course, they dilligently did most of the site in VB.NET (first fail) and stuck all the Page_Load() code on the .aspx files (second fail). The login screens are smart enough to check for SQL injection attacks ... but the GET query strings did not (third fail). I actually was able to deface the dev site with a simple URL as a proof of concept, and to ask for a complete rewrite of this site. Note: This was the DEV site, not production site, and yes I backed up the database before this. The problem  has usually been that

    - The "site" cost something like $30k

    - They were still asking the original devs to update the thing.

    Of course, they haven't done anything in over a year, so "Project: Recode" has finally been greenlighted. While on the job, one of the new devs found this gem:

     <FONT color=#ff0000><asp:Button id="LoginButton" CssClass="button" runat="server" Text=":: Login ::" OnClick="srch_mail"/></asp:button>
    </FONT>

    First of all, VB.Net isn't a fail.  Every stupidity that happened would have still happened if you forced them to do in all in C#.

    Second, anyone who creates a web site with a single SQL Injection vulnerability has no idea what they are doing.  If they had to "check for SQL injection attacks", then they were doing it wrong.  If you do it any one of ten right ways, you can completely forget about injection forever.

    Third, $30k isn't a big deal, even outsourced.  I paid well into six figures for my last outsourced conversion of a 30,000 line VB6 app converted to .Net.

    To me this is a huge project oversight fail.  Someone should have reviewed the site as it was being developed.  They should have noticed these patterns very early in the cycle and demanded a new team or training.  The outsourcing companies have tons of employees and seem to assign new people or bad coders to the projects that don't complain.  If you speak up, the issues will be addressed.



  • @Someone You Know said:

    Care to explain either of these for those of us who don't know anything about .NET web development?

    @Someone You Know said:

    @danixdefcon5 said:
    ...and stuck all the Page_Load() code on the .aspx files...
     

    Bad, because it mixes layout and procedural code in the same file.

    @Someone You Know said:

    @danixdefcon5 said:
    <asp:Button id="LoginButton"
    CssClass="button" runat="server" Text=":: Login ::"
    OnClick="srch_mail"/></asp:button>

    Only thing I can see here is the "ID" is in small letters, and C# web apps are case sensitive - sometimes this builds properly, sometimes not. Also, a login button is calling a function named "srch_mail" - which sounds wrong if you speak English.



  • @Someone You Know said:

    @danixdefcon5 said:

    ...and stuck all the Page_Load() code on the .aspx files...
     

    @danixdefcon5 said:

    <asp:Button id="LoginButton" CssClass="button" runat="server" Text=":: Login ::" OnClick="srch_mail"/></asp:button>
     

    Care to explain either of these for those of us who don't know anything about .NET web development?

    Check that asp tag closely. It uses XML-ish tags, where you can have the following:

    <asp:tag attribute="something"></asp:tag>

    or

    <asp:tag attribute="something" />

    Now check the tag. Notice something ... weird? 😉

    Oh, and the Page_Load() thingy is because .NET uses a clever design for separating code from the "view" stuff (that is, HTML stuff). All the HTML goes on dummy.aspx, all the code goes on dummy.aspx.cs or dummy.aspx.vb, depending on which language you're using.



  • @Someone You Know said:

    @danixdefcon5 said:

    ...and stuck all the Page_Load() code on the .aspx files...
     

    @danixdefcon5 said:

    <asp:Button id="LoginButton"
    CssClass="button" runat="server" Text=":: Login ::"
    OnClick="srch_mail"/></asp:button>
     

    Care to explain either of these for those of us who don't know anything about .NET web development?



    Page_Load() is called whenever the page is loading, it is generally bad form to do much there.

    As for the second one, the value of the attribute 'OnClick' is the name of the function called on the backend when the button is clicked (the Load one mentioned above also is called).  The example given looks technically valid, but in the way that makes one nervous about the quality of the code.



  • @Jaime said:

    First of all, VB.Net isn't a fail. 
    It is if they initially decided they were going to use C#.@Jaime said:
    Second, anyone who creates a web site with a single SQL Injection vulnerability has no idea what they are doing.  If they had to "check for SQL injection attacks", then they were doing it wrong.  If you do it any one of ten right ways, you can completely forget about injection forever.
    Agreed.@Jaime said:
    To me this is a huge project oversight fail.  Someone should have reviewed the site as it was being developed.  They should have noticed these patterns very early in the cycle and demanded a new team or training.  The outsourcing companies have tons of employees and seem to assign new people or bad coders to the projects that don't complain.  If you speak up, the issues will be addressed.
    Agreed.



  • @locallunatic said:

    @Someone You Know said:

    @danixdefcon5 said:

    ...and stuck all the Page_Load() code on the .aspx files...
     

    @danixdefcon5 said:

    <asp:Button id="LoginButton"
    CssClass="button" runat="server" Text=":: Login ::"
    OnClick="srch_mail"/></asp:button>
     

    Care to explain either of these for those of us who don't know anything about .NET web development?



    Me being dumb
     

    Looking back over things I'll just fix that last post of mine.



  • @Jaime said:

    Second, anyone who creates a web site with a single SQL Injection vulnerability has no idea what they are doing.  If they had to "check for SQL injection attacks", then they were doing it wrong.  If you do it any one of ten right ways, you can completely forget about injection forever.

    The fun thing is that 'checking for SQL Injection attacks' wasn't in our list, at least not originally. It was after one of the management guys started reading about SQL Injection stuff that we started probing the app. But then again, the fact that the thing was already a boo-boo was pretty much common knowledge, so anything would be expected. Note: the app also crashed after 30-ish users loaded the main page ... because some of the DB code didn't even close the DB connections.

    The rewrite is actually implementing "SQL injection safe" stuff.

    @Jaime said:

    Third, $30k isn't a big deal, even outsourced.  I paid well into six figures for my last outsourced conversion of a 30,000 line VB6 app converted to .Net.

    Check my location. $30k is well over my yearly income, and I'm  already in the upper side of the average income for Sysadmin/DBA people. But the resulting code is something I'd expect from someone being paid $20.

    @Jaime said:

    To me this is a huge project oversight fail.  Someone should have reviewed the site as it was being developed.  They should have noticed these patterns very early in the cycle and demanded a new team or training.  The outsourcing companies have tons of employees and seem to assign new people or bad coders to the projects that don't complain.  If you speak up, the issues will be addressed.

    Agreed on the oversight, however I forgot to mention that the "outsourcing company" actually consists in something like 5 people coding away. In this case, it seems that all of them  are bad coders. I'm pretty sure that they will never get another project again. The SQL Injection finding was reported to them ... more than a year ago. They haven't fixed it, so the in-house devs are fixing those things as well.



  • Just out of interest, have the outsourcers actually received any cash for this rubbish?



  • @danixdefcon5 said:

    @Jaime said:

    Third, $30k isn't a big deal, even outsourced.  I paid well into six figures for my last outsourced conversion of a 30,000 line VB6 app converted to .Net.

    Check my location. $30k is well over my yearly income, and I'm  already in the upper side of the average income for Sysadmin/DBA people. But the resulting code is something I'd expect from someone being paid $20.

    I noticed your location when you I originally posted.  I can see why we outsource to India and China here in the US, we save a ton of money but lose oversight.  We usually end up spending a lot of the savings fixing exactly the problems you are experiencing.  What I can't understand is why anyone would outsource to the land of $15US-per-hour programmers when local programmers cost about the same.  Outsourcing barely makes economic sense here in the US, why are you even considering it?  Just because the outsourced programmers don't make much less than you doesn't mean you should expect higher quality from them.  Outsourcing takes a lot of management if you want good results.

    @danixdefcon5 said:

    @Jaime said:

    Second, anyone who creates a web site with a single SQL Injection vulnerability has no idea what they are doing.  If they had to "check for SQL injection attacks", then they were doing it wrong.  If you do it any one of ten right ways, you can completely forget about injection forever.

    The fun thing is that 'checking for SQL Injection attacks' wasn't in our list, at least not originally. It was after one of the management guys started reading about SQL Injection stuff that we started probing the app. But then again, the fact that the thing was already a boo-boo was pretty much common knowledge, so anything would be expected. Note: the app also crashed after 30-ish users loaded the main page ... because some of the DB code didn't even close the DB connections.

    The rewrite is actually implementing "SQL injection safe" stuff.

    If you guys just learned about SQL Injection, you shouldn't be writing web apps.  Wait until you learn about cross-site scripting, or "Padding Oracle" attacks.



  • @Jaime said:

    I noticed your location when you I originally posted.  I can see why we outsource to India and China here in the US, we save a ton of money but lose oversight.  We usually end up spending a lot of the savings fixing exactly the problems you are experiencing.  What I can't understand is why anyone would outsource to the land of $15US-per-hour programmers when local programmers cost about the same.  Outsourcing barely makes economic sense here in the US, why are you even considering it?  Just because the outsourced programmers don't make much less than you doesn't mean you should expect higher quality from them.  Outsourcing takes a lot of management if you want good results.
    I was thinking about that, but presumably if a job's not what you do, you would expect to hire in someone from outside to do it. A lot of outsourcing isn't done to cut costs, but because people imagine it will be done better, or with more come-back, than if done in-house.



  • I know that outsourcing is ridiculous, and it wasn't to India ... it was a local developer house which shall remain unnamed. These guys just learned it the hard way ... the project was already going to hell when I started working there. Even then, it took them a full year to finally realize everything was FUBAR'd. I'd like to add that no-one had even checked out the source code before sending it into production. The $30k was only for the stuff that actually crawled its way into production, I think the total cost was going to be something like $200k... but that's been obvioulsy cancelled.

    @Jaime said:
    If you guys just learned about SQL Injection, you shouldn't be writing web apps.  Wait until you learn about cross-site scripting, or "Padding Oracle" attacks.

    SQL Injection was one of the key issues I pointed out in my original plan. All the in-house stuff has been coded from the ground up to avoid those attacks; the problem  was that the outsourced project didn't follow those guidelines.



  • @Jaime said:

    First of all, VB.Net isn't a fail.  Every stupidity that happened would have still happened if you forced them to do in all in C#.
    You are absolutely correct.  The only real-world difference between VB.NET and C# is the color of the candy coating.  After compiling, the chocolate inside (the MSIL instructions) are the same.

    Outside of real-world differences, there are a few things that have implementations in C# that weren't implemented in VB.NET.  Even VB6 wasn't bad as long as you didn't try to go beyond the limitations it had.  If you were running into VB6's limits, you were using the wrong tool for the job.

    I've said it before to many people:  Bad code in Visual Basic will crash the app.  Bad code in C++ will crash the OS.  (and the reason there are more bad coders in VB is because the ones that did it in C++ have their heads on pikes due to the angry mob of users)



  • @henke37 said:

    Of course not, it is clearly using POP3 instead.

    Oh, ok. I was going to say...



  • @Jaime said:

    First of all, VB.Net isn't a fail.  Every stupidity that happened would have still happened if you forced them to do in all in C#.

    Sorry, but VB.NET is a fail. Of course you can fail in C#, too, but...well, I've recently been forced to work on a legacy ASP.NET site in VB.NET (I normally do C#), and about every other day I find myself cursing VB.NET to the bowels of hell for some stupid syntax thing or another.



  • @toth said:

    Sorry, but VB.NET is a fail. Of course you can fail in C#, too, but...well, I've recently been forced to work on a legacy ASP.NET site in VB.NET (I normally do C#), and about every other day I find myself cursing VB.NET to the bowels of hell for some stupid syntax thing or another.

    I'm with you on this one. I'm maintaining a horrid winforms app right now that was originally written in VB6 and then ported to VB.NET. This steaming pile of fail has If blocks nested six deep (wtf) with no curly braces (wtf). It contains such gems as a 1500-line method (wtf) that takes eight string parameters by reference (wtf), plus four by value. Yes this atrocity could have been just as easily committed in C#, but in VB the missing braces and ByVal ByRef And Also Not For Each bullshit makes me downright homicidal.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.