Page 8 of 18 First ... 678910 ... Last
  • Jump to page:
  1. 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
    32
    >>And it should be pointed out that nothing very important
    >>should be put on those sites, anyway.
    Would you provide definition of 'very important'? Surely, amazon or ebay will not host there, and so shouldn't any more or less respectable eshop or any other kind of site that get personal information. But the thing is that they don't. Who does use shared hosts, however, is those people who are either just learning or do not think their info is worth $100mo+$for pro, and that is totally fine. Not mentioning that shared hosts *can* be configured to be failry secure.

    >>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.
    It is indeed, but I still stand strong on my opinion that vast majority of visitors here aren't professionals or at least not in this field. Those who do make buck or two find themselvs in positions where they ought to learn sec stuff or they will be out of business.

    >>But .HTACCESS doesn't need to be avoided. It's a good way to
    >>get familiar with the syntax and concepts of configuration, anyway.
    That is correct, but why should one jump head first using as main security shield something he has little or no idea about? Or even something that he just started learning/using?

    >>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.
    If someone figures out a way to write an .HTACCESS file on a site they will also find way to read a .php file.

    >>Joe or Jo Developer should practice the best security he or she
    >>knows, and ought to be learning as much as possible.
    And my purpose of coming here is to help them out. What's yours?
    And you know I mean that.
  2. film at 11
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2000
    Location
    Portland, OR
    Posts
    413
    Rep Power
    14
    2. Be careful with eval() Placing user-inputted values (especially non-validated ones) into eval() functions can be extremely dangerous. You essentially give your user the ability to execute any command he wishes! Just imagine that you _think_ your input is coming from a nice drop-down select input, limiting their input to what you think is safe. But again, suppose your user called your script like this:

    script.php?input=;passthru("cat /etc/paswd");

    By putting his own code in that statement he would cause your program to output your complete /etc/passwd file! It's that simple.

    Use eval() sparingly. I have seen a lot of code where it appears to be used for no reason whatsoever (to evaluate code that could be evaluated right there in the script, but for no real reason is run through eval() using user input). If you do need to use eval, CHECK THE INPUT VERY WELL.
    I'm going to add to this, because it seems like the only one of these (excellent) points that hasn't been elaborated on. This example comes from a project I revisited after reading this thread a few times.

    I used eval() when I had:
    1) an unknown function to run on a given object,
    2) a function to run on an unknown object, or
    3) both- unknown function, unknown object.

    This resulted in code that went something like this:
    PHP Code:
    $func function_name_from_input_or_database;
    $obj object_name_from_input_or_database;

    eval(
    "$".$obj."->".$func."(".$value_from_user_input.");"); 
    yikes. I thought that I couldn't write this directly in PHP, so I had to build a string that looked like what I wanted to do, then eval() it... wrong! To avoid using eval() when working with unknown objects or functions, you have to remember that PHP supports both variable variables, and variable functions. The above should have been written like:
    PHP Code:
    $$obj->$func($value_from_user_input); 
    Since $obj has a string representing the name of some object in scope, $$obj is that object. Furthermore, if the string in $func is a valid method of $obj's class, PHP will attempt to evaluate that method. This also works for regular functions.

    From the manual:
    http://www.php.net/manual/en/functio...-functions.php
    http://www.php.net/manual/en/languag...s.variable.php

    Hope this helps someone avoid the mistakes I made.
  3. No Profile Picture
    Dev
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Jan 2001
    Posts
    1,436
    Rep Power
    41
    Originally posted by jrees
    Who is going to configure those servers?
    Maybe you should
  4. 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


    Maybe you should
    Wrong answer.

    The only people who are going to configure those servers are the people who own them, or someone they hire.

    Wait. There's a "joke" going around that the best sysad is the guy who owns the back door.

    If there is no motivation, those servers are going to continue to be open to attack and/or already taken over. Security is everyone's business.
  5. 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 AlCapone
    >>And it should be pointed out that nothing very important
    >>should be put on those sites, anyway.
    Would you provide definition of 'very important'?
    If letting it get in the wrong hands could directly or indirectly cost me more than a day's work or a day's pay, I would not put it on a server I couldn't secure myself:

    Passwords, ID numbers, account numbers, birthdates, names of real people in many cases, ...

    And if I were going to bother password protecting a site, I would not keep a password file in any directory a browser could see. Even if I were just playing around, I would warn the visitors against re-using important information in their passwords.

    Surely, amazon or ebay will not host there, and so shouldn't any more or less respectable eshop or any other kind of site that get personal information. But the thing is that they don't. Who does use shared hosts, however, is those people who are either just learning or do not think their info is worth $100mo+$for pro, and that is totally fine. Not mentioning that shared hosts *can* be configured to be failry secure.
    And if they can be, they should be, I'd say.

    >>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.

    It is indeed, but I still stand strong on my opinion that vast majority of visitors here aren't professionals or at least not in this field. Those who do make buck or two find themselvs in positions where they ought to learn sec stuff or they will be out of business.
    So why not encourage them to learn before they go out of business?

    >>But .HTACCESS doesn't need to be avoided. It's a good way to
    >>get familiar with the syntax and concepts of configuration, anyway.

    That is correct, but why should one jump head first using as main security shield something he has little or no idea about? Or even something that he just started learning/using?
    And why not encourage them to learn? Instead of JeffCT saying things like, "Hide it in a file with the .php extension." I would prefer he said something like, "You can sort-of hide the contents of files by giving them a .php extension, but don't rely on this trick too much."

    >>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.

    If someone figures out a way to write an .HTACCESS file on a site they will also find way to read a .php file.
    That ain't exactly true.

    >>Joe or Jo Developer should practice the best security he or she
    >>knows, and ought to be learning as much as possible.

    And my purpose of coming here is to help them out. What's yours?
    Ditto.

    I've seen a lot of un-trained people who can write a little HTML get pressed into jobs because professionals aren't available. I've seen a lot of "pros" who rely on the .php extension, and it seems to work the first time, so they never learn to do it right.

    I've also seen a lot of people who don't realize that, with search engines available, whatever they put on the web is at least as much available to the public as what gets scrawled on the wall beside the public telephone (or in the public restrooms).
  6. Banned (not really)
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 1999
    Location
    Brussels, Belgium
    Posts
    14,642
    Rep Power
    4476
    Yeah, yeah...okay...we got it. Every server should be properly configured and it's our responsibility to do so.

    Can we just get back to specific security issues, please, and how to avoid/eliminate them?

    ---John Holmes...
  7. /(bb|[^b]{2})/

    Join Date
    Nov 2001
    Location
    Somewhere in the great unknown
    Posts
    5,163
    Rep Power
    792
    [qoute]
    >>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.

    If someone figures out a way to write an .HTACCESS file on a site they will also find way to read a .php file.
    That ain't exactly true. [/quote]
    Sorry, I just have to comment on this one...

    This is true, if someone can create a .htaccess file on your site and not have legitimate access, it is just as easy to create a php file that has a view source function connected to a get string, or exec/passthru etc, etc in it.
  8. No Profile Picture
    Dev
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Jan 2001
    Posts
    1,436
    Rep Power
    41
    Anyway, as SepodatiCreations said, let's get back to the topic. If you would like to write your own thread about how to properly configure a server, go for it.
  9. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2002
    Location
    Galway, Ireland
    Posts
    7
    Rep Power
    0
    Originally posted by SepodatiCreations
    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!)
    A handy way to avoid people posting their own form to you is when validating the input, validate $_SERVER['HTTP_REFERER'] to make sure the input isn't coming in the back door.
    Gamers Europe :: Keeping it Simple
  10. 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
    32
    Originally posted by Donncha

    A handy way to avoid people posting their own form to you is when validating the input, validate $_SERVER['HTTP_REFERER'] to make sure the input isn't coming in the back door.
    Possible but not reliable since it is up to browser whether or not to send referrer. Plus, it can be easily spoofed.
    And you know I mean that.
  11. 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
    This whole HTTP_REFERER thing has me thinking: why can't there be a non-spoofable way to check the referer? Maybe some sort of temporary key delivered to the form, and checked upon submission -- maybe tied in with the session key, so that it could never be spoofed, or at least, spoofing would be a real pain. Even better yet would be some sort of RFC for POST operations in general that would do something with SSL keys to force a referer.

    At the very least, you could set a session in the form, and then check it upon submission, so that the spoofer would always have to at least go to the trouble of loading the form, accepting the cookie, etc... to start spoofing. Also, don't allow more than a few submissions from the same IP address/[browser footprint] within a short time.

    But in the end, you still have to assume that you could receive any value into your form handler, so it wouldn't be a final security measure, but at least it could reduce troublesome "submission-bot" traffic.
    (In 2000, the company I was working for had an old CGI script for free classified ad submissions. I started seeing dramatic load on the server occasionally, so I checked once at peak activity. There were literally over a hundred instances of the script running. All coming from the same place. I tracked it down to some internet marketing^H^H^H^Hspam firm who was selling space on our website, and running a script to fill up our system with thousands of ads a day.)
    The real n-tier system:

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

    Amazon wishlist -- rycamor (at) gmail.com
  12. 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
    32
    racymor has a point there that one can make non-spoofable referer value, but it just won't fly too high. As far as I can remember, they allowed people to disable ref. value because of this security-privacy rush some years ago, and it just won't make it nowadays. At least not public and not forced.

    And I think as to registration spam, the way major portals do is fine by me (random picture with word/numbers on it), although I do wonder how long it'll take for someone to write algorithm that analyzes pictures.
    And you know I mean that.
  13. 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 Onslaught

    That ain't exactly true.
    Sorry, I just have to comment on this one...

    This is true, if someone can create a .htaccess file on your site and not have legitimate access, it is just as easy to create a php file that has a view source function connected to a get string, or exec/passthru etc, etc in it.
    (With apologies to JeffCT for piggybacking his thread one more time,)

    Well, that ain't necessarily true, either. It's close, but if it were completely accurate, .HTACCESS would be much more than just a band-aid.

    If the server is set up correctly, .HTACCESS files are not (barring some unforeseen bug) inherently weak. It's some of the corner cases, where the simple view stated by Onslaught above (and earlier by AlCapone) doesn't hold, that cause the headaches. So, you should prefer to restrict the setup to the main server configuration as much as possible.

    Be aware that *NIX does not use levels of access, by the way. You can give write access without giving read access, which is sometimes useful. This can be one of the corner cases, but there are others.

    Hmm. I should point out that it's necessary to correctly specify access both from the system point of view and from the server point of view.

    Anyway, if you can use .HTACCESS files but can't set the server configuration, go ahead and use them. It makes for good practice, and it raises the wall a bit.

    I'm half inclined to think that it's okay using the .php extension to hide the contents of non-source data that you want hidden, _if_ that's all you have. But it is not reliable, and if .HTACCESS controls are available, .HTACCESS should probably be given control instead.

    In addition to server setup issues, if the version of php is old and unpatched, the .php extension may be only protection against the casual visitor. There is a known bug, and there are known exploits for the bug.

    With the .HTACCESS controls, you can completely deny access to a specific file type, or completely deny access to all file types except, say, .html and .php. That means you can specify that some file types will simply never be accessible, interpreted or otherwise, by someone typing the file's URI into a browser. You can also divide your personal home directory into sub-directories for serving html, sub-directories for serving php, and sub-directories that are not served at all, which is even better.

    But you should test the results, just to make sure the main server setup doesn't defeat you.

    One thing to remember when specifying the access for a directory, you usually want to deny directory listing access. A directory devoted to download is an exception, of course.

    How do you learn all these cool settings? Download apache, get it running on your own personal machine as a private network of one machine (http://127.0.0.1 or http://localhost) and start messing around. Just don't forget to shut apache down before you dial in to your isp.

    If you're not too careless, you can develop your pages on your own machine and only upload what works. Developing on your own machine leaves you some more options for backup, too.
  14. 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 rycamor
    This whole HTTP_REFERER thing has me thinking: why can't there be a non-spoofable way to check the referer? Maybe some sort of temporary key delivered to the form, and checked upon submission -- maybe tied in with the session key, so that it could never be spoofed, or at least, spoofing would be a real pain. Even better yet would be some sort of RFC for POST operations in general that would do something with SSL keys to force a referer.
    It's an interesting thought, but you're right that it would require encryption and some fancy playing with keys. Could be done, server side, with the present technology.

    Thinking casually about this, it sounds like it would look a lot like sessions without cookies. You end up tracking your users in the URL, since that's how you would set the URL of the referring page. Sounds like more work than it's worth.

    But what have you got against sessions? Is it the use of cookies, or is it the use of the URLs when cookies aren't available? Something else?
  15. 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
    32
    >>You can give write access without giving read access
    Can it be done? You bet. Is this the case on most host? Not just no, but hell no.

    >>How do you learn all these cool settings? Download apache,
    >>get it running on your own personal machine as a private
    >>network of one machine and start messing around
    This is my personal favorite - do you really think that we do not have apache installed on local box and that all we do is based on some shared host somewhere? If so, then until you start making reasonable posts I will try to withhold from further commenting on this issue.

    jrees, we are going in circles here - it is obvious that neither you nor me is going to change his mind, so let's stop hitting each other's tail and start doing something productive.
    And you know I mean that.
Page 8 of 18 First ... 678910 ... Last
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo