• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Native sessions or CI sessions.

I said that. Because that is the case.

PHP's native sessions uses a simple session cookie (by default called PHPSESSID), which contains only the unencrypted session ID.

Getting that is often quite easy, unless you never go to any website with your browser (I can do that using this forum if need be, all that's needed is a link to what you think is an image, and make sure you click on the link) . Once I have your session id, I can access the application with your credentials. I don't need to hack your server, and I don't need to hack your PC. You obviously don't have a clue of the dangers lurking in the real world.

As the session ID doesn't change unless you have programmed a manual rotation of the ID, I have all the time in the world to use that ID to access the site.

On shared hosting, the hosting company needs to take special precautions to make sure the server based session files are not accessable across websites. In my experience that is absolutely not always the case, especially for the low budget hosters. Write a script that scans the disk for session files, and just open them. Piece of cake (as your apache instance needs read/write access to those files).

If you refer to a CI session library that uses PHP's session mechanism, some of this issues might be mitigated since you're not using the full native PHP stack, you're only using the server storage side. Which makes cookie hijacking more difficult. Server side the story remains the same.

If you're concerned about speed, you should be worried about the fact that the standard CI session library (and all derived libraries) do a storage update every time you update the session. Which could explode the number of I/O's to the session storage backend within a single page request. Solving that issue gives a bigger gain in speed than mere switching from DB to file storage.

If you really want something fast, use a session system backed by for example memcached and remove I/O from the equation alltogether.

As to your last points, I prefer to ignore your remark about noobs. I've been busy with CI's session system for a very long time, I've written replacements that mitigate the shortcommings of the current library, and also wrote the session engine for another framework. I believe I'm entitled to say that I know what I'm talking about... Before you write a post like this, get your facts together, and come with arguments to prove I'm wrong. So far, I haven't seen any...

session ID wont give you anything in case developer not a noob - but this is not a native session problem, it is that person so called developer problem.

in CI implementation of the native sessions exists the same security measures as in DB driven sessions implementation.

both of the ways transfer session IDs

once again if noobie developer do not lets say check password during the login routine but only login and once login is hijacked ... and this super great application was written in CI, will you claim CI as a source of the problem and call it "bad framework" or will you claim that developer who dont check password but only login because he forgot or simply noob who decided that no one will never know some one else's login ?

the same situation with the native sessions - if some one implements them without security in mind - shame on him, but this is not a native sessions problem, this is problem of the developer mind absence.

well known CI extensions which allows you to use native sessions already have the same security measures as database driven sessions implementation - so, topic starter can use them without problems.

about file storage vs database storage and speed ... some one simply forgetting the fact that:
1) database is also uses files to store data
2) database has queue which could be simply stopped lets say in myisam by some stupid update (and many other cases - this one just the simplest case came in mind)
3) sending query to the database , searching for the data and receiving results i'm sure in 99% taking more time than read the file

even without searching for the data step (which could be pretty time taking in big databases), just send-receive will take more time than read file.

4) ohh yes and dont forget about updating the table AND reindexing it Smile
etc ... so forget about the database way

You're not getting the point.

How do 99,9999% of the applications use a session:
- user goes to website, enters as guest/unauthencated user
- user goes to a login page (most of them not encrypted btw)
- user types in userid and password, and clicks submit
- application validates the credentials
- if valid, an 'id-value' is stored in the session linking the session to the user
- session cookie containing the session id is sent to the browser

When the user requests an other page on that same site
- browser sents cookie to the application
- application extracts the session id and loads the session data
- application checks if a valid 'id-value' is present in the session data
- if present, the link to the user is looked up
- application sends the result back, with the user as being logged in

Where in the second step of this process is there any user interaction? Nowhere. There is no password check there. And I'm willing to bet that your applications aren't any different. This is what sessions do: maintain state.
So if I can get hold of that cookie, and there is no mechanism to make sure I can't use that cookie, I can hijack your session.

Now, as I already said, if you're talking about CI's implementation or the alternative libraries floating around that are based on CI's implementation (note that the "CI Native Session library" is NOT the same as PHP native sessions, and that is what started the discussion!), the cookie hijacking issue is mitigated due to the extra checks introduced by the library (IP & agent checks, and a rotating ID which limits the lifetime of the stolen cookie).

As far a speed is concerned, the impact of reading one record and writing one record per page request is virtually nothing compared to all other I/O generated by the application. It will probably never be as fast as direct disk I/O (unless your RDMBS has the table cached), but the benefits of having the data in the database more than outweigh the extra cost involved (backup/restore, load balancing, offloading or multi-tier solutions, easy application access to session data (ever tried to determine the number of logged in user with native session files?), etc). Something that is very clear in any business context. And furthermore, hardware and processing power is dirt cheap, and therefore no factor in the discussion.

However, the cost and impact of a security breach for any company can shoot up a mile high before you know it. And, as said, if speed is a real consideration, use memcached backed sessions. All the speed, none of the security risks.

People that worry about these trivial things are those who decide to host their websites at the GoDaddy's of this world. Which imho says enough...

exactly, if some one asking for such a things it is most likely that his application wont require all of the benefits of the completely database driven site, his database wont be located in the dedicated DB cluster etc... most likely his application will be hosted on the shared hosting where database load and query execution is very important and time taking ... thats why in case your application not smth like yahoo and hosting budget not at least several hundreds per month (at least to have 2 separate servers) then no reasons to store session in the database ....

more over routine described by you absolutely applicable and to the database driven sessions - no difference where to store in case of security lack ...

in case of use CI session handling libraries - i would suggest to use popular native session library ...

to the topic starter:
forget about encrypted cookies at all ...
in case of shared hosting forget about database driven session implementation ...

better use native session implementation library ...

I suggest with advice like this, you give up on all other security features as well.

Passwords? Why have the users go through one more screen? Oh, you do use passwords? Why hash them, store them in plain text. XSS filtering? Not needed. URI filtering? Same deal. Output escaping? Ridiculous.

Sigh... I give up...

[quote author="WanWizard" date="1302307060"]I suggest with advice like this, you give up on all other security features as well.

Passwords? Why have the users go through one more screen? Oh, you do use passwords? Why hash them, store them in plain text. XSS filtering? Not needed. URI filtering? Same deal. Output escaping? Ridiculous.

Sigh... I give up...[/quote]

useless irony when dont have arguments in support of your point of view Wink .
btw XSS filtering should be used also not everywhere Smile it is resources taking thing so use it wise Smile

I gave the arguments, but you can't be bothered. Which is fine by me. I don't care what kind of insecure code you produce.

But someone who gives other people the advice to use PHP sessions in a shared hosting environment, to dump cookie encryption, and to be slack with XSS filtering is just plain dangerous. And that makes me angry.

Some bedtime reading: http://phpsec.org/projects/guide/. Especially the section on data filtering, sessions and shared hosts. And the TS can judge for himself.

*cough* Session variables: seven deadly sins *cough*

LOL @n0xie

The only reason see why users use native sessions is because they can not get them to work with CodeIgniter sessions.


[quote author="WanWizard" date="1302308051"]I gave the arguments[/quote]

so what is your arguments for this and how SQL stored sessions are better than native file stored sessions in case of both of them uses the same CI session security and verification mechanism - the only difference one way store in database another natively in files:

1) how SQL stored are more secured than native ? both ways uses the same CI library way mentioned above.

2) explain me how DB stored could be faster than native ?

even replication wont force sql stored to be faster than native ... any ways connection time, any ways sql execution time, any ways reindexing time, any ways locks/queues in case of myisam, in case of inno - even slower on inserts/updates than myisam

session ID hijacking - not a problem because used the same session library security algorithm ...

in case of hacked server - both file stored and DB stored are not secured any more.

so ... your reasons for DB stored ? what the advantages, say me ... i dont see any ...

about xss - as i said - should be used wise, but fore sure should ...

Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  

  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2021 MyBB Group.