ECommerce with integrated one-click hacking



  • A client of the firm I work for is interested in floating a trial balloon in ecommerce airspace, but isn't willing to build a full (and expensive) infrastructure should they decide to not proceed past the test stage. They looked around a bit and found some places they could outsource the whole process to (inventory, order taking, billing, shipping, etc...) and had us take a look around at those systems.

     

    Our first go-around at the prime candidate's system found a few nice WTFs:

    a) The shopping system passed around the session token in the URLs (well, ok, some people haven't joined the cookie generation yet, but this system enforced URL-based sessions on everyone, whether you're using the "telnet to port 80" browser or the latest greatest IE/Opera/FF/NS)

    b) The session token was a simple incrementing integer (yikes)

    c) The shopping system was 'generic', in that by changing a few parameters in a config file or whatever, you could rebrand the whole system to fit the client's needs (look 'n feel, layout, etc...). But instead of using a server-side configuration, all config parameters are passed (where else) in the URLs.

    d) It uses frames for layouts (aiiiiiigh!) 

    So... site's totally vulnerable to session hijacking. Not good. Also totally vulnerable to cross-site-scripting (XSS). Also not good

     
    So we write up a report, and tell the candidate company of the problems with their site. They didn't see how the XSS vulnerability was a problem, but agreed that the session business could stand a bit of developer attention.

    We eventually got them around to our point of view by saying "What if someone replaced the 'clientName' parameter content with '<a href="http://pornsite.com/ohlala.jpg">'... what do you think will show up in the site?".

     

    "Oh."

    They get on the horn to the company they'd purchased this shopping monstrosity from to report these problems, and get informed that these aren't problems, but the contractors would be happy to fix the problems, but there'd be a substantial charge for the candidate company.

    Very nice. Sounds like a certain very large monopoly out there. "Sure, there's problems, but upgrading to the next version for the low low price of $TOO_MUCH might fix them!"

     

    --- time passes ---

    We get informed that the shopping system has been upgraded to the newest version which fixes all the problems we reported. We go and poke around. Hmmm. There's still a session token being passed in the URL, but it's been changed to a literal 'xxxxx_CartVendorName_xxxxx' string. Interesting.... We poke a bit further and find they've re-implemented sessions with a cookie, with a somewhat random looking alphanumeric session token. Ok. that's fine.

    So why is that sessionID parameter still in the URL? Hmm. I poke at the URL and delete the entire session parameter, and uhoh... the site's layout is now broken. 1 of the frames is showing content from a complete different site. So the session token no longer controls tokens, but does determine what shows up in the navigation frame. But... the same session token is used for ALL the branded sites this system is hosting. Interesting...

    More poking later, I find that all the XSS vulnerabilities are still present. You can still inject arbitrary content into the site by replacing pretty much ALL the query parameters in the URL. Oh joy...

    And then I stumble onto the ultimate WTF on the site purely by accident... Not only is the site XSS vulnerable, but it's also SQL injection vulnerable...


     

    In my earlier testing, I hadn't at all considered the possibility that some of these query parameters might actually be roundtripped and used in a background database... I hadn't put any SQL metacharacters into the test strings I was XSS injecting. So purely by chance...

    *holds head and reaches for the Motrin*

    Wish I could be in on the conference call when my report's presented....
     

     

    p.s. Access? Oy veh.... It's one thing to entrust national elections to biased vendors peddling questionable hardware/software and questionable methodology... but this is my (and everyone else's) credit card info we're talking about...

     



  • I would have done them a favor and dropped their tables. It would prepare them for how their pants would get dropped and they would get reamed when someone showed how one lone person could blow away their whole site.



  • I recommend to replace the image since it actually shows the name of the software.



  • Well, my report is pretty detailed and includes screen captures of the site before/after the various injection attacks are exploited. The screen cap for the SQl problem is followed by:

     

    Note that the URL “CustID” and “BuyerID” parameters have been inserted into the SQL query verbatim, and that there is NO escaping of SQL metacharacters (ie: apostrophes). This allows execution of arbitrary SQL queries by users by simple manipulation of URLs – ie: complete remote control of the database


  • This kinda reminds me of a company that I worked for not to long ago.  I managed to find a SQL injection vulnerability and contacted the appropriate people about it.  The only response that I got was that it wasn't really a problem because I had to change the page locally (to avoid the client side validation).  After some argument, I managed to convince them that it was necessary by truncating the table with all the user information in it while the CEO was using the system.


    Needless to say, when the CEO says to fix something, it gets fixed. 



  • [quote user="un.sined"]

    This kinda reminds me of a company that I worked for not to long ago.  I managed to find a SQL injection vulnerability and contacted the appropriate people about it.  The only response that I got was that it wasn't really a problem because I had to change the page locally (to avoid the client side validation).  After some argument, I managed to convince them that it was necessary by truncating the table with all the user information in it while the CEO was using the system.


    Needless to say, when the CEO says to fix something, it gets fixed. 

    [/quote]

    IME in corporate America, even though you were right, you're lucky to have kept your job.  Might there have been a less dramatic way to explain the weakness? 



  • [quote user="Sgt. Zim"][quote user="un.sined"]

    This kinda reminds me of a company that I worked for not to long ago.  I managed to find a SQL injection vulnerability and contacted the appropriate people about it.  The only response that I got was that it wasn't really a problem because I had to change the page locally (to avoid the client side validation).  After some argument, I managed to convince them that it was necessary by truncating the table with all the user information in it while the CEO was using the system.


    Needless to say, when the CEO says to fix something, it gets fixed. 

    [/quote]

    IME in corporate America, even though you were right, you're lucky to have kept your job.  Might there have been a less dramatic way to explain the weakness? 

    [/quote]

    It was a test environment, so we were expected to be doing things like that.  Besides, trying to get dev to fix things in the system was like pulling teeth, though mandates from above were always top priority.


     



  • [quote user="un.sined"][quote user="Sgt. Zim"][quote user="un.sined"]

    This kinda reminds me of a company that I worked for not to long ago.  I managed to find a SQL injection vulnerability and contacted the appropriate people about it.  The only response that I got was that it wasn't really a problem because I had to change the page locally (to avoid the client side validation).  After some argument, I managed to convince them that it was necessary by truncating the table with all the user information in it while the CEO was using the system.


    Needless to say, when the CEO says to fix something, it gets fixed. 

    [/quote]

    IME in corporate America, even though you were right, you're lucky to have kept your job.  Might there have been a less dramatic way to explain the weakness? 

    [/quote]

    It was a test environment, so we were expected to be doing things like that.  Besides, trying to get dev to fix things in the system was like pulling teeth, though mandates from above were always top priority.
    [/quote]

    Ahh; I should have realized that it was in a test environment.  I'm too used to seeing projects go out the door with no testing ("the customer is our beta tester!"), so I naturally assumed that this was production code we were talking about.

    On doing odd things in testing, that reminds me of an order entry system that someone else was developing; a certain tester discovered that it initially allowed for ordering negative quantities, and for discounts of greater than 100%.  Oops.  At least it was found in testing, rather than after it went live. 



  • That story would have had enough WTFish potential to be on the front page. It by far exceeds the WTFery of other Sidebar-WTFs.



  • whoa, blast from the past!  I joined a company with a similar system, my role was to "improve" the system which after discovering a host of wtfs like you listed became a total rewrite.  Chances are the shopping system company is mostly led by the sales team and the coders are either way to rushed, not listened to when they point out that they "need more time to fix x" or their just a bunch of the cheapest recent graduates the company could find...  I remember pointing out that if speed was of the essence then they could use that opensource shopping system that's about.  Customising the theme would of been most of the work and would of took a lot less time but the powers that be where certain that if its opensource than it's surely crap and easily hackable.  Talk about ignoring the lead devs opinion :¬/


Log in to reply