Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
The Internet

A Guide to Building Secure Web Applications 126

Posted by michael from the much-needed-little-heeded dept.
some-guy writes "The Open Web Application Security Project has released A Guide to Building Secure Web Applications, Version 1.1 "While this document doesn't provide a silver bullet to cure all the ills, we hope it goes a long way in taking the first step towards helping people understand the inherent problems in web applications and build more secure web applications and Web Services in the future...""
This discussion has been archived. No new comments can be posted.

A Guide to Building Secure Web Applications More

A Guide to Building Secure Web Applications

Comments Filter:

  • Secure Web Applications (Score:5, Insightful)

    by kenp2002 ( 545495 ) on Wednesday September 25, 2002 @11:51AM (#4328491) Homepage Journal
    I wonder if they are going to cover Project Managment which is the leading cause of poor security. When the project runs short on time security tends to be left till last and when your short on time, functionality out-ranks security (After all what good is the security of the app doesn't work? Right?)
    • I agree. Bad management and bad planning lead to many errors (not just security). When I worked in web development (intranet) I was amazed that the developers for the external stuff didn't do any security planning until after their code was audited. Then they just fixed anything that the audit turned up. It has been said before and should be said again: If you want something to be secure you have to build it that way from the ground up.
    • Aside from project management, I would also consider project specifications as being a contributing factor.

      I know security can suffer heavily if a project starts to get into a time crunch, but in how many projects was security even a consideration in the first place?

      If anyone starts working on a network-based project on a base install of any operating system (Windows, Linux, even OpenBSD), then there are problems well before the project's deadline approaches.

    • As far as I can see from the document index, it doesn't cover it. Around a year ago I did quite some research on this topic and I found one document that covered all aspects (including the management part) very well. Unfortunately I lost the link (i'll reply to this if I happen to find it again).

      The first few chapters of that document described how you should see security in your entire company. Be realistic: if loosing creditcard-information is not going to harm your stock, why should you put effort in securing it? On the other hand, if it means your credibility as a trustworthy company diminishes, you (as a developer) will be more likely to have budget to set things up in a secure way.

      Bottomline: explain to your boss how much $$$ is involved with certain choices, let him do the math in Excel (they are really good at that). If they understand that they will loose money when a webapp is compromised, they will be very likely to give you the opportunity to write decent software.

  • TOC (Score:3, Funny)

    by bytesmythe ( 58644 ) <bytesmythe@@@gmail...com> on Wednesday September 25, 2002 @11:56AM (#4328543)
    Chapter 1 - Fdisking your machine
    Chapter 2 - Installing linux
    Chapter 3 - Updating OpenSSL libraries

    What else do you need? Oh, yeah...

    Chapter 4 - Unplugging your network connection
    (That should lock it down from outside pretty well.)

    Chapter 5 - Removing your harddrive and pounding it with a big ass sledgehammer.
    (Now it's secure from the INSIDE, too.)

    See? Good network security really isn't so hard.

    • >Chapter 1 - Fdisking your machine
      >Chapter 2 - Installing linux
      >Chapter 3 - Updating OpenSSL libraries
      >Chapter 4 - Unplugging your network connection
      >Chapter 5 - Removing your harddrive and pounding it with a big ass sledgehammer.

      Chapter 6 - ???
      Chapter 7 - Profit!
    • I think the cheapest (and undoubtly best) security is to take your computer to the nearest bank and stick it in their safety deposit box!

      • chapter n: digging a hole in your backyard (or whatever passes for a backyard), filling it halfway with concrete mix, placing pc in concrete mix, then covering with more concrete mix.... Now we can't even tell what kind of computer was in there (... was there a computer in there?)
  • If security was Easy, it would be less secure. For something to be secure, it needs to be sufficiently different and obscure to prevent 95% of all attacks. there is not a "inpenetrable" fortress, but i do believe you can make steps to come closer to a goal of keeping most attackers out. If there was an end all secure solution, i would be out of a job
    • If security was Easy, it would be less secure. For something to be secure, it needs to be sufficiently different and obscure to prevent 95% of all attacks

      That sounds suspiciously like security through obscurity, which we all know *DOES NOT WORK*.
      I've done some web apps that require a login, either to the standard /etc/password (/etc/shadow) or to a database of some sort. Sure I could make it very obscure, but if instead of validating that username and password everytime a page loads and instead passing a variable saying LOGGED_IN="TRUE", I defeat my own security by making it vary easy to bypass my login.

      As the article says, validating input, and failing securely are two of the most important things you can do. If you're expecting a phone number, don't accept anything except numbers (and possibly -) as input. And make sure that if the system fails, it doesn't leave you wide open, it actually shuts down.

      • I did mention DIFFERENT befor OBSCURE. Micro$oft is a great example of insecurity by obscurity... the list of flamebait could go on, but you get my picture.
    • Make it to obscure and you might intrigue the hacker witht the challenge.. unless its some young script kiddie
      • i am a phonetic speller. Ill correct the parent.

        Make it too obscure and you might intrigue the hacker with the challenge...Unless it is some young script kiddie.

      • the goal is to prevent the script kiddies flat out. really good hackers are never going to be stopped. just eta for hack lengthened
    • I don't think so.

      A big-ass deadbolt in a solid metal frame is secure without being obscure.

      Bringing a gun to a knife fight is more secure - especially when everyone else sees your piece

      The US's fighting stance vis Iraq is certainly not "security through obscurity"

      I could go on, but you get the idea.

      Now - on-topic - There wasn't much at the site that wasn't covered better elsewhere IMHO.

      Regards, Tom

  • **security** (Score:3, Insightful)

    by buswolley ( 591500 ) on Wednesday September 25, 2002 @12:04PM (#4328642) Journal
    Companies that develope security related products surely spend a portion of their budget on promoting security fears.(Especially easy with M$).. The average business manager is easily scared when a big security firm issues a warning about impending viruses, security holes etc.

    My experience is there is much less out there than the hype may lead you to believe..

    And there is no such thing as security when a talented hacker wants your network bad.

    So..Just don't make yourself an easy target. If the average networked business provides itself with enough security to make a hacker actually have to WORK!! at it to get in, then you will filter out most attacks; unless the hacker has a specific interest in your company's network.

    • Obscurity. Work. yes yes.

      But also this: If a hacker's probe reveals an interesting security method, wouldn't that just make that hacker more interseted in defeating it; for the challenge, and fame?

    • Re: **security** (Score:4, Insightful)

      by Anonymous Coward on Wednesday September 25, 2002 @12:16PM (#4328778)
      I work at a web application security consulting company and do pen-tests on large corporations web applications regularly. I can tell you from experience that the hype *is* real. I have *never* seen a medium to large sized web application infastructure that does not have holes in it. I have always found a way to get customer records, administrate the site, or some other essential flaw. People do not know how to program securely, or even know that they have to. Guides like this are an excellent. If I were a manager, I would have all of my developers read it.

      As far as your "there is no such thing as security" argument, I think it's pretty silly. Yes, if a hacker is ultra hardcore and is going to spend an inordinate amount of time breaking into your ISP's domain server to conduct man in the middle attacks or use advanced 0-day techniques, it is difficult to defend against. But a well designed, programmed, administered and protected (think Snort) system is an incredibly difficult thing to break into. A good IDS will stop unknown buffer overflows. A good administrator will not leave backup files out on the webserver. There is a lot that can be done to improve security to the point where you can be reasonably certain that you are secure. What would you have people do, say "Oh, a really great hacker can get into my system anyway, so I'm not going to bother with security anyway."
      • And you are right. There is a lot of holes. And you can make it really hard for a hacker to get inside the system.

        My point was that a dedicated and talented hacker still can do it in most cases. In this sense, true 100% security is hard if not impossible.

        But good security implementation is still a must.

        Like this:An experienced car-thief might be able to break into my car and drive it away in under a minute. But that doesn't mean I should leave the keys in the door or joe average smo can take it.

        But you are right in everything you say about security. I don't think we were really disagreeing.

        • Security should be layered:

          So once you've made it hard for the hacker to get into the system, also make it pointless. If the data that resides on the system is also strongly encrypted, than obtaining valuable information is not only hard it is a collossal pain, and beyond the capability of anyone except maybe NIST. BTW SSL as implemented by Web servers and browsers can't maintain encryption of data through to the back end, you need a third party product for that ( Yes they exist [entrust.com]).
    • cracker not hacker.. cracker not hacker.. cracker not hacker.. REPEAT AFTER ME!

      That being said.. do you run apache? Were you running it during the 'year of the worms'? Did you ever see the logs? Suffice it to say.. it is a bigger problem then you give it credit for.

      As for the 'no such thing as security'... I have to say.. I find it quite esoteric and not rooted in reality. Sure.. in theory.. you may very well be correct. Of course if your target is a well audited OS with software carefully chosen (by you) with services handpicked and configured then the 'no security' argument falls flat. Oh yea.. anything can be cracked (as in.. not hacked.. cracked) given time... but alas.. so often that time is after a programs primetime.

      People who think there is no security and any cracker can own you if they try needs to rethink computer security. This isn't windows afterall :P

      (cracker... not hacker.. ;)

  • Version 1.2 (Score:5, Funny)

    by Shagg ( 99693 ) on Wednesday September 25, 2002 @12:07PM (#4328669)
    A Guide to Designing Web Applications That Will Survive a Slashdot DoS Attack.

  • Examples are a must (Score:4, Interesting)

    by Photon Ghoul ( 14932 ) on Wednesday September 25, 2002 @12:08PM (#4328673)
    I like where they are goign with this, but....

    Does anyone really think that telling a developer that "they must validate input", for example, is really going to do any good? If the developer is lazy or even better (since laziness is no excuse) a newbie , perhaps they would be better served with some example code. A few brief snippets in popular languages covering common circumstances would go a long way to help reduce widespread security holes.

    For example, a Perl snippet showing how to check for the validity of an email address. A VBScript snippet providing an example of comentizing for the sake of seperating out privelages. PHP snippets demonstrating resuse of trusted components.

    Just a thought.
    • or even better a spellchecker for me.

      For clarity, "comentizing" is "componentizing".
    • Security is an area of programming in which examples can actually harm the quality of code. I don't mean to defend STO, but rather to point out that it's unlikely that the toy system used in a guide will be identical to the system under development by the reader of the guide. Both the inexperienced and the lazy face a terrible temptation to copy-and-paste whatever snippet they can find that they can convince themselves is applicable to the situation. A programmer is better served by being informed of the issues involved, and then forced to work out for himself what those issues mean for his code.

      later,
      Jess

    • There's an excellent book called "Writting Secure Code" (by Microsoft Press would you believe it), that talks about security in great depth.

      I recommend anyone shooting their mouth off here to read it before they do.

      But on topic with the parent post, it says "adopt the idea that examples are actually templates" (or something along those words). What he means is that writting an example that doesn't check for error return codes (or memory overrun issues) will most probably end up in insecure code being written.

      Seriously though, anyone talking about security should read such a book before they do.
    • If you just give programmers a few examples and tell them to validate input, you will certainly get insecure code. This is not necessarily due to laziness or inexperience, but to lack of standardized code. If there are 20 different ways to validate the same type of input, there is little hope of anything working.

      For instance, retrieving and parsing a URL is basic task that should have one and only one low-level function. It should check for valid information, throw away invalid information, and deliver a clean set of data that the programmer can use. If programmer does not use this function, that is negligence. If the function was never developed, then the project manager should be sacked.

      This goes for everything. Requests to databases should have a standard layer to validate that the data is as expected. The functions to calculate hashes should be in one place.

      The ludicrous fact is that these things do not exist because people people feel they need to create an optimized version for each application. Well, then why do we buy multi gigahertz machines if not to make our lives easier? If a web server or compiler results in a slow web page, then replace the technology instead of sacrificing security.

  • >> Access control mechanisms are a necessary and crucial design element to any application's
    security....a web application should protect front-end and back-enddata and system resources by implementing access control restrictions ... Ideally, an access control scheme should protect against the unauthorized viewing, modification, or copying of data.

    Yea, whatever. [wikipedia.com]

    This document does seem to be pretty good, but documents like this really need to be peer reviewed. Personally, I think a document like this would be better as a wiki than a pdf.

  • For those of you using PHP in particular... (Score:5, Informative)

    by angst7 ( 62954 ) on Wednesday September 25, 2002 @12:12PM (#4328726) Homepage
    As a supplimentary reading assignment, this months Linux Journal [linuxjournal.com] is running an similar, interesting article on Programming PHP with Security in Mind [linuxjournal.com].

    ---
    Jedimom.com [jedimom.com], choo choo choosing you...

    • Re:For those of you using PHP in particular... (Score:1, Informative)

      by Anonymous Coward
      While a generally very good article, I just had to laugh at the authorize example. OK, so using safe variables like $_SESSION is a good solution, how about INITIALIZEING YOUR FRIGGIN VARIABLES?!?! All one needs to do to fix the original 'broken' example is add "$authenticated = false;" at the top. Problem solved. Depending on defaults is just asking for trouble. Sure, $authenticated is PROBABLY defaulted to 'false', but, uhm, would it kill you to initialize it and get the peace of mind?

      Sometimes the simplest solutions are the best, and doing more is just overkill. For example, suppose your 1000 php file project depends on register_globals being on. Instead of 'fixing' all the code so that it uses $_POST, or $_GET, or $_SESSION or $_COOKIE (and you will ALWAYS have to test all of them if input can come from either), you can just stick a couple of loops in a top level include file that iterate through those globals and register the named variables themselves (with a couple of small checks, of course, hehehe).

  • "click through" (Score:5, Informative)

    by Conare ( 442798 ) on Wednesday September 25, 2002 @12:12PM (#4328736) Journal
    Any security mechanism should be designed in such a way that when it fails, it fails closed. That is to say, it should fail to a state that rejects all subsequent security requests rather than allows them

    This is one of my favorites. Most browsers fail SSL connections with a warning that allows the user to just "click through" if the certificate is expired, does not match the DNS name of the site, or is issued by an untrusted authority. Only the last of these should be a warning (since you may want to trust it anyway. The other two should be connection failures. I am glad they included this.
    • I read somewhere (netcraft survey?) 80% of SSL-certificates are invalid? Most are expired, and only about 5% are self-signed.

      I've never seen people so clueless about security as those who run web-shops. You sometimes can't think of a suitable answer to a webeditor who thinks their thwarte certificate will be a shiny new complete security solution to all possible ills.

    • Any security mechanism should be designed in such a way that when it fails, it fails closed.

      I agree with that in general, but you always have to take denial-of-service into account too. Can I disable all user accounts just by entering three bad passwords into the system?

      • No but you can disable that account which is the point. The other accounts don't come into it.
        A denial of service attack is obviously different to an intrusion.
  • I have perused the WASP security guide and they do a good job of covering the most common exploitation methods. I have decided to use the WASP paper as a foundation document for the security practices of our team. The security of your web application, like many other things has dependancies like the OS and web server software. The saying that security is only as strong as your weakest link comes to mind, but the important thing to note here is that the WASP paper concentrates on the realm of web applications only. Concepts like failing closed when you encounter errors are important logical conventions to implement in order to make your application secure. EVERY web application developer needs to understand the material covered by the WASP.

  • Sloppy samples (Score:5, Insightful)

    by phorm ( 591458 ) on Wednesday September 25, 2002 @12:24PM (#4328865) Journal
    I think that one of the bigger problems is the amount of self-started developers who rely on bad examples. When I first started programming Perl (and later PHP), I relied heavily on samples or articles online. In other cases, I picked apart common but easy programs.

    As a result of this, my initial coding was functional, but crap. Over 3 months I picked up a better coding style, and on looking back at my initial code I was surprised at how badly it had been written. While there are many good resources for starting to code in a particular language, many of these use shortcut-code to get the message across.

    For instance, PHP code that relies on "register_globals" is a bad example. For one thing, it doesn't work on all systems. For another, it can lead to programmers leaving holes or vulnerabilities in their sites. While it may be a pain to use $HTTP_POST_VARS["something"] every time, it's also nice to set an example of the most compatible method for coding.

    Crap code is like a virus. If you make crap samples, and then somebody else makes crap samples based on the knowledge gained from your samples... pretty soon you have crap^2. A good thread might be for everyone to list the best known sites for PHP/Perl/etc sample, as well as known coding baddies/goodies.

    "AND password=$password", not a good idea - phorm

    • Re:Sloppy samples (Score:2, Informative)

      by russcoon ( 34224 )
      I'm one of the guys running the project that's producing the Guide, and I can assure you that v2.0 will include language-specific examples and pitfalls.
      • If you need any help let me know (phormix at phormix dot com). I'd be more than happy to lend some examples of good and nightmarish coding.

        Oh, and kudos for this work. I was at one time working on a simple PHP manual, but ran out of time before it even really got started. I'd be happy to start it up again, and get assistance from the slashdot crowd. It can be found at: phpmanual.phormix.com

        Time for my server to get slashdotted? - phorm
    • The problem is that global variables made coding PHP easier, which was one of the big selling points of the language. They've finally set register_globals to off by default now, but the damage is done. So many PHP apps require it to be on that it can be a major pain in the ass to fix.

  • What bugs me (Score:3, Interesting)

    by Boss, Pointy Haired ( 537010 ) on Wednesday September 25, 2002 @12:40PM (#4329031)
    is the number of web application security prophesies who go on about SQL injection through form fields.

    Yes, it's all good and dandy in theory and makes you look very clever indeed, but count how many unknowns you have to know before you can attack a site in this way, do some basic probability math and your chance of success is so low you might as well phone the web master and ask them what the password is.

    • That said of course, this is no reason _not_ to create safe queries from form input, that's just (or should be unless you're in the wrong career) common sense, but that's not the point.

      These people make it out like it is easy to attack a site like this.

      I don't think it is.

    • Re:What bugs me (Score:2, Informative)

      by PhilipMatarese ( 609325 )
      Actually, this is a very common problem. There might not be many unknowns if a SQL execution error gets displayed in the middle of a page response.

      IIS by default will throw the SQL error into the response (making it easier for developers to debug). If a developer doesn't trap/handle this and a user sees the error come up, they can find out a lot about the system. Then the user adds some quotation marks in with there inputs, and they could pass SQL instructions direct to the database.

      This is a very real problem that occurs. Of course, the user would probably not be able to do meaningful damage without knowing the backend of the system, but they could still screw up your data tables.

    • Re:What bugs me (Score:2, Informative)

      by pVoid ( 607584 )
      that's where you're wrong.

      Security vulnerabilities aren't a person going "mirror, mirror, oh randomness mirror, give me a random string to hack this site".

      it's all tied in together. For example securely failing is part of it. I personally will almost always check if a website can handle single quotes in HTML fields. Some of them do, some of them don't. Others don't and give away some such glarringly compromising error message that you can actually see the SQL statement.

      here's a very simple one, take it home, think of it...

      my user name is :

      "Adam' \n go \n sp_addlogin 'myhaxx' , 'yourpass' \n go \n select '' = '" This statement might not even fail if the orginal statement is:

      EXISTS( SELECT * FROM myUsers WHERE UserName = $UserName )

      It's not as hard as you think it is, and just because you can't think of something, don't go thinking nobody else can.

      Security is about being humble really.

    • remember that most of us deal with open-source code: if someone can see your code, whether it be in C or in PHP, they can look for holes. injection throught SQL is a big problem -- if someone's feeling malicious, they just have to figure out what you're running (and if it's one of the popular php-forums, that's not hard) and download the code ... and start having a look around for potential security flaws. doesn't take much.

      it's irritating to write as much code as it takes to be secure, but i'm glad i did it with my project -- it doesn't allow anonymous stuff at all, but there are still risks involved ... so every single page, whether creating forms or accepting input from forms, re-verifies absolutely everything about what you're allowed to do, etc. there's no reason for create_object.php to make sure you can, and create_object_confirm.php not to.

      and there's no reason not to make sure your SQL is secure. (although not using the most-used server also helps -- i use firebird/interbase ... most people expect you to be using mysql, and will attack it as such.)

    • Yes, it's all good and dandy in theory and makes you look very clever indeed, but count how many unknowns you have to know before you can attack a site in this way, do some basic probability math and your chance of success is so low you might as well phone the web master and ask them what the password is.

      Which, with SQL server admins, might actually work!
      • No, with SQL Server admins, you don't have to ask.

        User: sa
        Pass: blank

        That's the way it comes off the CD, that's the way it will stay until the coming of the four horsemen (and I don't mean Rick Flair and crew.)

    • Fuzzers, proxies, stupid apps, and the limited number of SQL dialects in use today make this attack not just theoretical. In theory, yes, there are a lot of variables in play, but the intelligent attacker can quicly whittle this down. Are they hosted on IIS? Yes? Then the odds are pretty high they're using MSSQL too. It's not rocket science (or skiddies wouldn't be the ones doing it).

      SQL injection is only one problem, but the results of it's success (given the poor defensive posture of most web apps) are usually catastrophic. It's not the root cause of most problems, but it's something that we can't just ignore. Like it or not, it's dangerous. The authors of the Guide (myself included) would be remiss in not including it.

      More generally, canonicalization of input and sanity checking external inputs is the root cause of most security problems (not just in web apps) today. Calling it "clever indeed" ignores the severity of the situation and the truly atrocious state of security (which directly is related to code quality) of most deployed apps.

      We're not trying to be clever. We're trying to be practical.
    • ... is that people dismiss the injection attack because they think there are too many unknowns.

      You can tell pretty quickly if the machine is going to be vulnerable (e.g. if you can execute arbitrary SQL commands), and, if it is, it is rather easy to determine if there are quick exploits available.

      If you consider only "query injection", where you need to know something about the data, then *some* work is required (so you *may* have a point).

      If, however, you look at "procedure injection", you can do some particularly nasty things if you can get to, say, xp_cmdshell ... (depending, of course, on the security context).

      Or, if you know that an input field will be placed into the HTML stream without proper supervision, just put in a nifty SSI or a scripted nasty.

      These things may not always work, but it is pretty quick work to determine whether or not they will ...

      Cheers,

      JAKD

  • Remember Me? (Score:2, Interesting)

    by duplicate-nickname ( 87112 )
    Something that is a very serious issue but is just brushed over in that paper is a method to remember who users are, long term....the "Remember Me" feature.

    Personally, I have left this "feature" out of my web-apps, but users are really demanding it, so how should it be handled?

    Obviously storing a username and password, or a user id number in a cookie is a problem. I am already generating session GUIDs, so it would be possible to store the GUID in a cookie, and then do a look up when they return to match the user account (which is already done on every page for state managment). This almost has the same problem as storing the username/password, as a malicous user would just need to find someone else's GUID and stuff it in their own cookie.

    So, was is the most secure method for remembering a user assuming you are already doing form-based authentication with SSL?

    Here's all this OWASP document has to say:

    Session tokens that do not expire on the HTTP server can allow an attacker unlimited time to guess or brute force a valid authenticated session token. An example is the "Remember Me" option on many retail websites. If a user's cookie file is captured or brute-forced, then an attacker can use these static-session tokens to gain access to that user's web accounts. Additionally, session tokens can be potentially logged and cached in proxy servers that, if broken into by an attacker, may contain similar sorts of information in logs that can be exploited if the particular session has not been expired on the HTTP server.
    • It's inherently insecure. Just don't do it, or make them perfectly aware of the risks and let them do the risk/worth analysis. That's why you'll never see an online banking service offer this type of thing, but you will see it all over forums and news/discussion type sites where the cost of leaking data is very low (or null).

  • another resource (Score:3, Informative)

    by tommck ( 69750 ) on Wednesday September 25, 2002 @01:20PM (#4329409) Homepage
    There's also a decent book out called Quality Web Systems [amazon.com] (I know... amazon! here it is at bookpool [bookpool.com]) that might be useful to some. It talks about lots of aspects of securing (and testing that security) web sites.

    T

  • Mirror (Score:2, Informative)

    by russcoon ( 34224 )
    We've got a mirror of the guide up [wi2600.org] (fat pipe generously donated by the wisconsin 2600 chapter [wi2600.org])

    If you're interested in helping out with the project, check out our SourceForge project page [sourceforge.net] and drop me a line [mailto] if you'd like to contribute or have suggestions or patches. The whole thing is now in DocBook format, so diff's are always appreciated.

  • DOWNLOAD SITE FIXED (Score:1, Informative)

    by Anonymous Coward
    I host the main download. Had some server issues along with 7.5mbit of bandwith being pulled through. Sorry about the download problems my generic fbsd couldn't handle it. Had to up max memory requests to 30k from 4k. - zeno@cgisecurity.com
  • Since it seems like OWAPS is being Slashdotted, I have set up a mirror here [earlham.edu].

  • URL modification and multiple SQL statements. (Score:4, Interesting)

    by tetranz ( 446973 ) on Wednesday September 25, 2002 @02:56PM (#4330330)
    Whenever I see something like http://mydomain.com?id=1234 I can't resist inserting a semicolon in the number. Its very common for this to create an error exposing the SQL statement and leaving me wondering what http://mydomain.com?id=1234;DELETE * FROM mytable (url encoded) would do. I would never do something like that but something like http://mydomain.com?id=1234 OR 1=1 often yields interesting results.
  • They should check out what RFP has to say over at wire trip [wiretrip.net]. He is pretty savvy when it comes to software security.
  • For another book on writing secure programs, see my "Secure Programming for Linux and Unix HOWTO" at http://www.dwheeler.com/secure-programs [dwheeler.com]. It's free, and it covers both web applications and non-web applications.

Slashdot Top Deals

It's a naive, domestic operating system without any breeding, but I think you'll be amused by its presumption.

Close