Page 7 of 18 First ... 5678917 ... Last
  • Jump to page:
    #91
  1. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2002
    Posts
    3
    Rep Power
    0
    A good link which covers many of the points raised (and some new ones, I think) is

    Secure Programming in PHP > http://www.zend.com/zend/art/art-oertli.php



    Sil
    http://www.the-scream.co.uk
  2. #92
  3. No Profile Picture
    Dev
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Jan 2001
    Posts
    1,436
    Rep Power
    42
    Originally posted by andnaess
    Eh... All the trouble? It's one bloody line in the apache config, and once it's done I never have to worry about it...
    What about your arguments about writing portable code? Like developing with register_globals off and checks for magic quotes. Doesn't using that Apache band-aid make it a little more difficult to keep things portable?
  4. #93
  5. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Nov 2000
    Posts
    204
    Rep Power
    15

    One point I didn't see covered


    Although for the most part MD5 on your password will cover the problem, if there's anything you wouldn't want anyone else to see, make sure not to pass it into the url. Why? Because if one of your users accesses a page with:
    Code:
    page.php?user=bob&pass=enter
    and then surfs to another site, if the person on that other site goes through their referer logs, the referer page will offer up the full url including the password!
  6. #94
  7. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2000
    Posts
    35
    Rep Power
    15
    Surely you'd be better off using 'post' forms to pass passwords rather than 'get' as then it wont be part of the url, and also not to pass it on between pages in the URL string, but use sessions or somthing else instead.
  8. #95
  9. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Nov 2000
    Posts
    204
    Rep Power
    15

    holy, er, moly


    I just read part of http://www.securereality.com.au/studyinscarlet.txt
    and gosh this part "got" me, never dawned on me!!:

    As mentioned earlier, variables in PHP don't have to be declared, they're
    automatically created the first time they are used. Nor are they
    specifically typed, they're typed automatically based on the context in
    which they are used. This is an extremely convenient way to do things from a
    programmer's perspective (and is obviously a useful feature in a rapid
    application development language). Once a variable is created it can be
    referenced anywhere in the program (except in functions where it must be
    explicitly included in the namespace with the 'global' function). The result
    of these characteristics is that variables are rarely initialized by the
    programmer, after all, when they're first created they are empty (i.e "").

    Obviously the main function of a PHP based web application is usually to
    take in some client input (form variables, uploaded files, cookies etc),
    process the input and return output based on that input. In order to make it
    as simple as possible for the PHP script to access this input, it's actually
    provided in the form of PHP global variables. Take the following example
    HTML snippet:

    <FORM METHOD="GET" ACTION="test.php">
    <INPUT TYPE="TEXT" NAME="hello">
    <INPUT TYPE="SUBMIT">
    </FORM>

    Obviously this will display a text box and a submit button. When the user
    presses the submit button the PHP script test.php will be run to process the
    input. When it runs the variable $hello will contain the text the user
    entered into the text box. It's important to note the implications of this,
    this means that a remote attacker can create any variable they wish and have
    it declared in the global namespace. If instead of using the form above to
    call test.php, an attacker calls it directly with a url like
    "http://server/test.php?hello=hi&setup=no", not only will $hello = "hi" when
    the script is run but $setup will be "no" also.

    An example of how this can be a real problem might be a script that was
    designed to authenticate a user before displaying some important
    information. For example:

    <?php
    if ($pass == "hello")
    $auth = 1;
    ...
    if ($auth == 1)
    echo "some important information";
    ?>

    In normal operation the above code will check the password to decide if the
    remote user has successfully authenticated then later check if they are
    authenticated and show them the important information. The problem is that
    the code incorrectly assumes that the variable $auth will be empty unless it
    sets it. Remembering that an attacker can create variables in the global
    namespace, a url like 'http://server/test.php?auth=1' will fail the password
    check but the script will still believe the attacker has successfully
    authenticated.
    Now I finally understand why it's important to declare variables! And how this "shortcut" is a security risk and to write code properly requires being even more vigilant than declaring variables would have been whew! Maybe I should take a PHP course? Any in NY?
  10. #96
  11. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2000
    Posts
    35
    Rep Power
    15
    I dont think this kind of stuff can be learnt. It's the kind of thing you really need to think about, and pick up more easily when working on stuff. These security issues often apply to other languages aswell such as asp and java servlets or jsp pages.

    I'd say read (and think about) the whole of this thread, as it covers most issues quite well.
  12. #97
  13. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2000
    Location
    London, England
    Posts
    64
    Rep Power
    15

    Security


    6. IF YOU DON'T WANT PEOPLE TO SEE IT, GIVE IT A .PHP EXTENSION.

    If you have a start session include file, by giving it a .php extension is that not a security risk as somebody could start a session simply by calling the php file?
  14. #98
  15. Banned (not really)
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 1999
    Location
    Brussels, Belgium
    Posts
    14,651
    Rep Power
    4493
    Here's a small security issue I just found out about today. It's called CRLF Injection and can affect mail() and possibly other classes used to send mail.

    How is works is that if a user can take your form that sends an email, and send a Subject value like: "This is my subject\nBcc: myemail@myisp.com" then they will get Bcc'd on every email sent out when you use this Subject in mail. One method to do this is to download your form (save as), modify the usual 'text' box into a <textarea> and put in a subject like above. Note that it has to be an actual line feed like in a textarea, just using \n won't work b/c that'll be escaped by magic_quotes.

    The To: field in mail() might be vulnerable, too.

    I'm thinking that this should be a bug in PHP. I can't think of any reason this should be allowed. I've asked about it on the PHP List, too.

    All it boils down to is to continue to validate user input and make sure it's what it's supposed to be. Make sure your To: and Subject: in mail(), don't have any new lines...

    ---John Holmes
    (sorry for dredging up the old thread, too, but it is good reading!)
    -- Cigars, whiskey and wild, wild women. --
  16. #99
  17. // no comment
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Dec 2001
    Posts
    1,645
    Rep Power
    40
    wasnt this thread sticky once? how come its not anymore? btw, thanks for the warning on the mail bug.
  18. No Profile Picture
    lowest of the low
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2000
    Location
    Japan
    Posts
    12
    Rep Power
    0

    Re: continued...


    Originally posted by JeffCT
    6. IF YOU DON'T WANT PEOPLE TO SEE IT, GIVE IT A .PHP EXTENSION. It became common for awhile (heck I even did it) to name include files or library files with a .inc extension. Here's the problem. If a user simply types that .inc file into his browser, it will be displayed as PLAIN TEXT, not parsed as PHP. And even if his browser didn't like the file type, it would give him the option to download it. Imagine if this file had your database login and password, or even more sensitive information. All someone would have to do it type this into the URL (assuming for example that your .inc file is lib.inc):

    yoursite.com/lib.inc

    And its contents would be displayed in plain text. This goes for any other extension other than .php (and a few others), so even a .conf or a .cfg file wouldn't be safe.
    And I am wondering why on earth you have your include files, whatever you've named them, in the part of your file system visible to the web.

    The solution is to put a .php extension on the end of it. Since your include files or config files usually just define variables and/or functions and not really output anything, if your user were to load this, for example, into their browser:

    yoursite.com/lib.inc.php

    They would most likely be shown nothing at all, unless of your lib.inc.php outputs something. Either way, the file would be parsed as PHP instead of just displaying your code.
    Yeah, and then you have to worry about what that code will do when it's parsed stand-alone, like someone else pointed out.

    If it's nothing but functions and classes, you may think you're safe, but what about global constants? You really want those visible?

    So you really want the definitions accessible to who knows who, for playing around with?

    <tongue-in-cheek>Where's the pages you work on? I've no time to play games with them, but I think I could find someone who wants to practice.</tongue-in-cheek>

    There are also some reports of people adding Apache directives that will deny access to .inc files, however I do not recommend you do this, because it is not portable at all.
    Portable to what? Surely not M$PWS?

    If you rely on .inc files and that Apache directive to deny access to them and one day you move your scripts to another server and forget to place the Apache directive in, you are wide open.
    Oh. Good point.

    But since when are configuration files not part of the app?

    No, I tend to question the qualifications of anyone who can't remember to carry the configuration files along when he moves an app.

    Don't purposely write your software with a security flaw then put a band-aid on it. Write it properly the first time...
    What band-aid? That's not a configuration you usually want to have to use, but it is NOT a band-aid.



    -----

    That's all for now. I hope this has been helpful. I know many people will probably say "but that's common sense!".
    Let's try some better common sense: The configurations for php and apache which move your include paths out of your public file system are not hard. They work plenty well, and they allow you a lot of options in organizing your apps.

    For instance, you can write yourself a note in a file called "FORGET_ME_NOT.IMPORTANT" that contains the paths to all your configuration files (maybe you're using multiple languages?) and other things, like the dlls you're using and where you put them. And you can save that in a directory called, say, "app". And you can have two subdirectories of that called, say, "includes" and "visibles". And you can tell apache to serve "visibles" to the web and you can tell php to use "includes" as your include path:

    ~/home/webhome/app1/FORGET_ME_NOT.IMPORTANT
    ~/home/webhome/app1/includes/...
    ~/home/webhome/app1/visibles/...

    Simple? Logical? Easy to take every thing you need with you when you move it? And, best of all, your includes are not only never printed out in anyone's browser, but they aren't accessible to your ordinary hacker, either.

    {snipped}
    Feel free to add anything worth mentioning [/B]
    I did. I railed on you. Gently.
  19. No Profile Picture
    lowest of the low
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2000
    Location
    Japan
    Posts
    12
    Rep Power
    0
    Originally posted by JeffCT


    Nope, that actually won't stop anything

    If you use ../ the in filename it assumes you mean the directory above the current one. So if the path to include was something like:

    Yeesh.

    That is a poorly configured server.

    Want me to repeat that?

    No server should ever be allowed on the web configured like that. If someone can climb the file system like that and get beyond document root, that server is three minutes to 0wn3d.

    Rather than waste time pandering to the ill-informed, write up how easy it is to configure a server correctly. I mean, apache comes with an installer for M$Windows now, and the installer asks you where you want the default document root.

    Hey, Mac OS X even comes with apache set up right!

    No. I don't think your arguments about trying to avoid configurations are valid. Not at all.
  20. Mobbing Gangster
    Devshed Demi-God (4500 - 4999 posts)

    Join Date
    Sep 2001
    Location
    "Best City" 2002 and 2003- Melbourne, Australia
    Posts
    4,912
    Rep Power
    33
    >>That is a poorly configured server.
    Sadly enough, most shared hosts are that way and not you not anyone else can stop that from happening. The only thing that is left for developers is to develop for the worst possible scenario.

    >>If someone can climb the file system like that and get beyond
    >>document root, that server is three minutes to 0wn3d.
    Care to share how exactly?

    >>Rather than waste time pandering to the ill-informed, write up >>how easy it is to configure a server correctly.
    Like there isn't enough info on that already. Look, this is not Sepo's or Jeff's job to reinvent the wheel and give out free pro advices - this is no salvation army. This is, however, php forum where quite common security mistakes have been pointed out
    >>No. I don't think your arguments about trying to avoid
    >>configurations are valid. Not at all..
    I am *so* happy that you have dedicated boxes for each and every your client, but so many of us don't, and we have to work with somebody else's configuration files no matter how much wrong they are. Yes, developers do advice their hosts to change things to something better, and more often then not they follow advice, but as I have mentioned before one should hope for the best but code for the worst.
    >>And I am wondering why on earth you have your include files,
    >>whatever you've named them, in the part of your file system
    >>visible to the web.
    Good point which probably should be discussed in more details, but for vast majority of config files this is not an issue sicne information that is kept there is more of useranme/password sort of text. So making it .php will do the job just fine.
    >>what about global constants? You really want those visible?
    What about them? Since when does one echo all the config vars?
    >>So you really want the definitions accessible to who knows
    >>who, for playing around with?
    If it is badly configured shared hosting there really isn't much you can do about it.
    >>Portable to what? Surely not M$PWS?
    Not portable to hosts that do not allow overriding.
    >>No, I tend to question the qualifications of anyone who can't
    >>remember to carry the configuration files along when he >>moves an app.
    When was the last time you checked the audience this thread was written for? Average Joe Developer *does not* have qualification to think of all the security problems and differences in configurations.

    Don't get me wrong, jrees, everyone should speak out on any matter, but it's just that (I think) you are relativetly new to community and don't really see what sort of people we have here.
    And you know I mean that.
  21. No Profile Picture
    Dev
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Jan 2001
    Posts
    1,436
    Rep Power
    42
    Originally posted by jrees


    Yeesh.

    That is a poorly configured server.

    Want me to repeat that?

    No server should ever be allowed on the web configured like that. If someone can climb the file system like that and get beyond document root, that server is three minutes to 0wn3d.

    Rather than waste time pandering to the ill-informed, write up how easy it is to configure a server correctly. I mean, apache comes with an installer for M$Windows now, and the installer asks you where you want the default document root.

    Hey, Mac OS X even comes with apache set up right!

    No. I don't think your arguments about trying to avoid configurations are valid. Not at all.
    Until someone properly configures every single one of the hndreds of thousands (or millions?) of servers running PHP I would hardly consider my post not valid.
  22. No Profile Picture
    lowest of the low
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2000
    Location
    Japan
    Posts
    12
    Rep Power
    0
    Originally posted by JeffCT


    Until someone properly configures every single one of the hndreds of thousands (or millions?) of servers running PHP I would hardly consider my post not valid.
    Who is going to configure those servers?

    It's not that hard. It's few enough lines it could be copied out by hand and kept with, for instance, the pictures that were scanned into the site, worst comes to worst.

    And why should we all wait for all the other guys to fix theirs? Every properly configured site is one less place for the script kiddies to play.

    Understanding the file extensions is an important thing, yes. Abusing the file extensions is useful when you can't do anything else. But there is a better way.
  23. No Profile Picture
    lowest of the low
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2000
    Location
    Japan
    Posts
    12
    Rep Power
    0
    Looking through what you wrote, it seems that your whole point can be summed up right here:

    If it is badly configured shared hosting there really isn't much you can do about it.

    >>Portable to what? Surely not M$PWS?

    Not portable to hosts that do not allow overriding.
    To which I say, "just say no."

    If it costs anything, the ISP had better be giving better service than that.

    But, if someone simply MUST use the free sites, I suppose the advice about abusing file extensions to raise the wall a little beyond the rank amateurs level is good. But if we're going to be calling something "applying a band-aid", just which is "applying a band-aid"? And it should be pointed out that nothing very important should be put on those sites, anyway.

    And then you say this:

    >>No, I tend to question the qualifications of anyone who can't
    >>remember to carry the configuration files along when he
    >>moves an app.

    When was the last time you checked the audience this thread was written for? Average Joe Developer *does not* have qualification to think of all the security problems and differences in configurations.
    Your "average Joe Developer" had better _get_ the qualifications to think of basic security issues, or he had better _not_ be developing for anything but a hobby. Basic configuration _is_ a basic developer issue.

    Hmm. If the only configuration available is the .HTACCESS files, I'll acknowledge that you probably want to use the extension ".inc.php"idea as a little additional insurance. But .HTACCESS doesn't need to be avoided. It's a good way to get familiar with the syntax and concepts of configuration, anyway. Also, using the file system to organize your files is a good habit, and portable from server to server.

    And keeping notes is also a good habit, although you may want to keep the notes off-line if .HTACCESS is the limit of configuration available. Not for what goes into .HTACCESS, of course. If somebody gets around .HTACCESS, they've got that much of your configuration anyway. If you did keep your notes on-line, you'd want to give those files an extension like .text.php, too, to use all the protection you can get from the server settings.

    And you have to realize, if someone figures out a way to write an .HTACCESS file on a site that respects the .HTACCESS files, they may be able to quickly override the server settings concerning the .php extension. That depends on how tight the server has been set up.

    So, of course, you don't want anything really valuable or important (including password files) on a site where you have that little control. (Did I say that twice? Good.)

    Joe or Jo Developer should practice the best security he or she knows, and ought to be learning as much as possible.
Page 7 of 18 First ... 5678917 ... Last
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo