The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex
Mainly here are the risks:
ReplyDeleteSession hijacking
Session fixation
Consider using OWASP to do against it.
Also have a look at:
PHP Security Guide
Here is a good discussion on the subject: http://phpsec.org/projects/guide/4.html
ReplyDeleteThe answer by sAc is very good. However, don't rule out "sessions" because of this.
ReplyDeleteI've successfully deployed custom sessions which, among other things, fixes hijacking, password reversal (md5/rainbow) and (if used correctly) session fixation.
By "successfully deployed" I mean passing penetration testing and (of course) actually being better than the traditional.
There is no "secret" or obscure security; basically, it generates a random (and database-wise unique) number (actually, a guid in my case) per user account and stores the guid+username as the normal method (instead of username+hashed/salted password). Next, it binds this guid with the user's ip address. Not infallible, but using a guid and per-ip already is an improvement over the current session system. Of course, there are flaws which open up after specific targeting (such as ip spoofing+the hijacked guid and username). But in general, it's a way better alternative.
The biggest risk is if IPs aren't associated with a session, and session IDs are accepted without verifying they come from the IP that started them (or at least an IP in the same subnet). This allows someone to send a link to an already-started session, where the unwitting dupe might need to log in. Upon doing so, the SESSION is considered logged in -- and the hacker that sent the link (who already has the session ID) has access to our rube's account. Or it could happen the other way around, where the user's already logged in and doesn't have cookies enabled, so a PHPSESSID value is stored in every link. If the user pastes a link to someone, they're also effectively pasting their access to the site.
ReplyDeleteIn order to prevent this, a decent site will avoid starting a session til there's something to store in it, and keep track of what IP the session was intended for. And to exploit it, an attacker will look for a site that sends a PHPSESSID query string value in each link from the home page, or sends a similarly named cookie on the index page.
PHP Sessions use session identifiers, and haxxors can try all possible identifiers with a small change they got a valid one. Also, these identifiers are stored in cookies and can be intercepted. A third possibility is that PHP can be buggy and create two sessions with the same identifier. Also, session data is stored in files on the disk, which is unsecured. Instead, databases need a password.
ReplyDeleteIt is actually not possible to prevent the first two reasons, but the third and forth ones can be. For example, store your session data in a database.