1. No Profile Picture
    Another damn newb...
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2002
    Location
    BodÝ, Norway
    Posts
    94
    Rep Power
    13
    I myself place all .inc files inside a separate folder. Then I add a .htaccess file to this folder, containing the following two lines:

    Order allow,deny
    Deny from all

    This way, you can only reach the files inside this folder through include or require.
    Torkil Johnsen

    Never underestimate the power of stupid people in large groups...
    ---------------------------(Ú”,)----
  2. No Profile Picture
    <? unset($sanity) ?>
    Devshed Novice (500 - 999 posts)

    Join Date
    Jul 2003
    Posts
    613
    Rep Power
    11
    Originally posted by torkil
    I myself place all .inc files inside a separate folder. Then I add a .htaccess file to this folder, containing the following two lines:

    Order allow,deny
    Deny from all

    This way, you can only reach the files inside this folder through include or require.
    I was reading somewhere that if I didn't want my files that had .inc extensions to be read(parsed) as text, then I should use .php file extension instead. Which is what I do. But I like that idea that you're doing with .htaccess
    "I haven't failed, I've found 10,000 ways that won't work."
    - Thomas Edison

    -=Rick=-

    Chat Refinance Loans
  3. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2003
    Location
    FL USA
    Posts
    2
    Rep Power
    0
    if all you do is rely on sessions for validation check this website out
    http://www.acros.si/papers/session_fixation.pdf
    it talks about how people are taking over sessions.
    I change the session id on every page to keep up with this terror.
  4. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Nov 2003
    Posts
    3
    Rep Power
    0
    Learned a good lesson
  5. No Profile Picture
    <? unset($sanity) ?>
    Devshed Novice (500 - 999 posts)

    Join Date
    Jul 2003
    Posts
    613
    Rep Power
    11
    Why can't you validate your session ID's to give an error if a duplicate it trying to be acheved?
    "I haven't failed, I've found 10,000 ways that won't work."
    - Thomas Edison

    -=Rick=-

    Chat Refinance Loans
  6. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2004
    Location
    USA
    Posts
    1
    Rep Power
    0
    Regarding the security risks of using a variable to include a page, such as
    Code:
    $page = $_GET['page'];
    include( $page );
    In addition to adding a hardcoded extension,
    Code:
    include( $page . '.php' );
    or prefix,
    Code:
    include( 'myfile' . $page . '.php' );
    You can easily strip off any extraneous path information when you retrieve the value, like this
    Code:
    $page = basename( $_GET['page'] );
    include( 'myfile' . $page . '.php' );
    This way directory traversal by injection is defeated.
  7. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2004
    Posts
    4
    Rep Power
    0
    Very good to know. Thanks, JeffCT!
  8. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2003
    Location
    Arlington, TX
    Posts
    171
    Rep Power
    12
    Wow, excellent thread in its entirety. I'm glad I took the time to read through all of these. Wtg JeffCT, this thing made me aware of some very unnoticed security leaks in my code.

    Although it did turn my 2-line include to an 8-line monster for validation I figure security's worth the slight bloating of code.
    -Ahad L. Amdani
    Programmer/Developer
  9. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2004
    Posts
    9
    Rep Power
    0
    wat is escapeshellcmd ppl?
    -----------------------------
    http://www.zonelinks.com
  10. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2004
    Location
    Oslo, Norway
    Posts
    120
    Rep Power
    11
    Thank your the great advice.
  11. Titles are useless ;)
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2003
    Location
    Germanski West
    Posts
    216
    Rep Power
    15
    Originally Posted by oarko
    if all you do is rely on sessions for validation check this website out
    http://www.acros.si/papers/session_fixation.pdf
    it talks about how people are taking over sessions.
    I change the session id on every page to keep up with this terror.
    Really bad problem...

    vBulletin is not safe also eg.
    We had a guy that wrote a lil javascript which included an image to the site with a serverside script target and passing the users cookie in that url.
    (We are allowing html).
    He was able to "reuse" the session (and login) and broke into some accounts he got.
    Wasnt able to take 'em over, cause you need the current password to change the password.
    But was able to post, access restricted forums and read/download the private messages.

    Another javascript (without "stealing" cookies) was also done to post randomly generated threads.
    Pretty simple to implement. Simply open a new (hidden) window by javascript which points to another page containing a form with javascript based auto-submitter and using setTimeout functions to repeat frequently.
    Users will "open" that page when having javascript with openwindow enabled.
    This also is a problem with sessions (stored in cookies, but other ways also are possible) even if you dont know the actual session id of the "victim".

    Target was a vBulletin 3 (Beta 4?) board.
    Real bad one. Results in a high server load and also all the fake threads have to be deleted afterwards.
    And these fake threads itself could replicate the evil javascript code itself, so that the code spreads itself.

    Recommend to "censor" all script tags and all other stuff which might execute javascript code like the on* tag attributes in all scripts that allow "insecure" users to transmit raw and unfiltered html.
    I saw many scripts that use a censor mechanism stripping script tags but missing those other javascript on* attributes eg.
    Pretty dangerous.
  12. Banned (not really)
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 1999
    Location
    Brussels, Belgium
    Posts
    14,642
    Rep Power
    4476
    That's what you get for allowing HTML.
    -- Cigars, whiskey and wild, wild women. --
  13. Titles are useless ;)
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2003
    Location
    Germanski West
    Posts
    216
    Rep Power
    15
    Originally Posted by Sepodati
    That's what you get for allowing HTML.
    Sure, learning from mistakes.

    But the 2nd attack (posting random threads) is also possible by simply letting users click on a link.
    And links might be done even when disallowing raw html.
    The cookie and session of that user is valid, thus vB will accept the unwanted request to post the thread.
  14. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2004
    Posts
    1
    Rep Power
    0

    stupid question, perhaps.


    is there any really safe? I mean, without serious bugs?
  15. No Profile Picture
    <? unset($sanity) ?>
    Devshed Novice (500 - 999 posts)

    Join Date
    Jul 2003
    Posts
    613
    Rep Power
    11
    Originally Posted by lauramali
    is there any really safe? I mean, without serious bugs?
    Yes. No coding whatsoever.

    Serisously. There is no way to TOTALLY secure something, there is always someone out there who is just smart enough to figure it out. Only thing you can really do is try to stay one step ahead of the game.
    "I haven't failed, I've found 10,000 ways that won't work."
    - Thomas Edison

    -=Rick=-

    Chat Refinance Loans

IMN logo majestic logo threadwatch logo seochat tools logo