Page 12 - [Everyone] Must read Security Notes

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

if all you do is rely on sessions for validation check this website out
URL
it talks about how people are taking over sessions.
I change the session id on every page to keep up with this terror.

Learned a good lesson

Why can't you validate your session ID's to give an error if a duplicate it trying to be acheved?

Regarding the security risks of using a variable to include a page, such as

In addition to adding a hardcoded extension,

or prefix,

You can easily strip off any extraneous path information when you retrieve the value, like this

This way directory traversal by injection is defeated.

Very good to know. Thanks, JeffCT!

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.

wat is escapeshellcmd ppl?
-----------------------------
http://www.zonelinks.com

Thank your the great advice.

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.

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.

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.