• (cs) in reply to Xepol
    Xepol:
    As an interesting side note, and a totally different WTF, who set the limit limit for editing posts to obscenely small time limits less than 10 seconds??


    The forum gremlins.
    I don't think there's anything Alex can do.
  • David (unregistered) in reply to Adi

    Anonymous:
    If maskerAmount is the "masked" amount and maskerDummy is "throw someone off", why is maskerDummy being passed in the Response?

     

    It's being passed in a very lame attempt to throw off anyone who knows about query strings from modifying the query string to try and trick the system.  Someone trying to trick the system is more likely to start trying to change the value of "tot" rather than "track", when in reality tot is a dummy value and track is the actual total, but masked.  [sarcasm]Of course we all know that they would only every try to change the value of tot, and never ever any other query string variable. [/sarcasm]

  • chocolateBar (unregistered) in reply to uber1024

    I can't agree somehow.

  • (cs) in reply to dubwai
    dubwai:

    (999999 - 100000 + 1)

    What's the point of doing that calcuation not only once but mutliple times?

    What's the point of even doing it once?

  • (cs) in reply to JohnO
    JohnO:
    dubwai:

    (999999 - 100000 + 1)

    What's the point of doing that calcuation not only once but mutliple times?

    What's the point of even doing it once?

    Everybody knows the more complicated the encryption the harder it must be to crack. "maskerAmount = ((((oTotal + 22) * 7 )) - 12) * 620" is much harder to crack than "maskerAmount = oTotal  * 4340 + 88040" (or whatever).

    --Rank

  • (cs) in reply to Ben Dover

    Anonymous:
    spotcatbug:
    Nobody beats The Whiz!

    Heheh... kudos for the Seinfeld reference...

    Actually, "The Wiz" is (was?) a NYC-area electronics chain store.  The slogan was "Nobody beats the Wiz!"

     

  • (cs) in reply to b1xml2
    Anonymous:
    1. Anyone trying to defend such methodology (as some have attempted to argue that it is reasonable to send the data via the query string) merely demonstrates a lack of understanding of what it takes to make secure and functional web applications.
    2. Protecting the data from tampering can take many forms: one could store the data in SQL Server with a timestamp or guid to provide the reference key. Alternatively, one could store it in the Session object (or in ASP.NET, one could store it in the ViewState and have enableMac property set to true)
    Invariably, any web developer who is still doing what this snippet does, exposing private data in the querystring ought to be publicly humiliated. They just give web developers a bad name and by no small measure, we have quite a significant mass of web programmers who are neither programmers of any decent distinction nor proponents of any worthwhile methodology.
  • (cs)

    The phantom of the opera is there...

    inside your code [:|]

  • David (unregistered) in reply to Adi

    The whole point of the response is to throw people off with saying the 'amount=' maskerdummy, when in reality the real total is in 'track='. 

  • (cs) in reply to AnonymousCoder
    Relying on query string for any significant input is in general a WTF; what would happen if a user changed qs values and resubmitted this page with maskerAmount=0 or maskerAmount=xxxWTFxxx?

    Neither is POST safe. I just had to mention it...

    I always code my webapps with the philosophy that everything the user send me (the app) is a _request_ to do something. Once this logic sets in the head, queries like "SELECT name FROM client WHERE clientid = '$clientid';" should set off some alarm bells.

    First, is the variable safe? (Assuming PHP) has addslashes() been run on the variable? Using hungarian notation on variables has proved very useful for me. I use the prefix "us" for all unsafe variables and "s" for safe. This way it's much more likely that I'll spot any security hazards.

    Second, this is an app where users keep track of their clients and how many hours to charge them for. Where's the check to see if that client "belongs" to the user requesting the name? If there is no such check, users may be able read each others data.

    This is much better: "SELECT name FROM client WHERE clientid = '$sClientid' AND owner = '$sUserid' LIMIT 1;"

    Just a newcomers two cents.

    Btw, love the site :-)

  • (cs) in reply to JThelen

    JThelen:
    While I think Apoch can take YAGNI, and shove it where the sun doesn't shine along with the rest of eXtreme Programming, he certainly has a point regarding the verification of goods in the cart against their current price at the time of checkout.

    Heh. Personally, I think XP is a complete travesty, and I loathe it as a development paradigm - but the XP crowd does have some important lessons to teach. Specifically, careful and judicious application of YAGNI (more as a principle of avoiding excess complication than a holy mantra) and a willingness to refactor anything and everything that suggests that it needs it. I've seen a huge boost in code cleanliness in all sorts of projects when these kinds of things are applied.

    Screw XP, yes... but rejecting all the teachings of something out of hand just because the whole is stupid is not wise ;-)

  • (cs) in reply to uber1024
    uber1024:
    Well, Alex.  I think it's time to shut down your site.  This is never going to be topped, IMO.


    You wish.

    (Yechnology marches on.)

    Sincerely,

    Gene Wirchenko

  • 8bit (unregistered) in reply to Maurits

    Uhm, how about a session variable already?

  • mikeb (unregistered) in reply to dubwai
    dubwai:

    (999999 - 100000 + 1)

    What's the point of doing that calcuation not only once but mutliple times?

    Those calculations are using an idiom for generating a random number bounded by a lower bound of 100000 and an upper bound of 999999 (ie., a number from 100000 to 999999 inclusive).

    The general algorithm is: ((upperBound - lowerBound + 1) * randNum) + lowerBound

    Of course, it would have made more sense to put that into a nice little function (assuming VBScript doesn't already have one), but this is one thing in the code that may be a WTF, but not an idiotic WTF.

     

  • (cs) in reply to Apoch
    Apoch:

    JThelen:
    While I think Apoch can take YAGNI, and shove it where the sun doesn't shine along with the rest of eXtreme Programming, he certainly has a point regarding the verification of goods in the cart against their current price at the time of checkout.

    Heh. Personally, I think XP is a complete travesty, and I loathe it as a development paradigm - but the XP crowd does have some important lessons to teach. Specifically, careful and judicious application of YAGNI (more as a principle of avoiding excess complication than a holy mantra) and a willingness to refactor anything and everything that suggests that it needs it. I've seen a huge boost in code cleanliness in all sorts of projects when these kinds of things are applied.

    Screw XP, yes... but rejecting all the teachings of something out of hand just because the whole is stupid is not wise ;-)



    All of the good tenets of XP, such as code reviews, have already been incorporated elsewhere.  Everything else, such as YAGNI, haven't, and with good reason.   YAGNI is self existent in good design;  if it wasn't in the design, then don't code it.  In other words, it's been around before XP, and will continue to exist long after that travesty goes away, which we can only hope it will. 
  • Dan (unregistered) in reply to Maurits

    Well sure, you could do all that. But W(hy)TF would you expose critical data like that in the first place? The page that needs the data should get it from the app, not the request.

Leave a comment on “The Phantom of The System”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article