Tag Info

You're right that a cookie is a bad idea, but the approach itself is misguided. The problem with these kinds of hard limits is that they make it easy for an attacker to create a DoS condition for the legitimate user, simply by putting in 10 incorrect email addresses. Even if you time-delay the attempts, the attacker can simply send a request every time the ...

You're relying on a principle called security through obscurity, which is generally frowned upon. There is a widely-accepted principle called Kerckhoffs's Principle which states: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge. An alternate, and more general, form of the principle is called ...

The OWASP top ten is an important list to get under control, but it is necessarily a little vague and make be difficult to translate the generalized best-practices into coding suggestions. A good rule to keep in mind is always assume your input is malicious, no matter where it comes from, as it can be difficult to imagine just how malicious input can be ...

The main reason why safe mode should be removed is because its doesn't work. Over the years people have found many ways of bypassing PHP's safe mode. But the lack of enforceability is only one reason reason why Zend chose to remove "safe mode". This is a quote taken from the PHP 6 minutes discussion: As safe_mode is a name that gives the wrong signals ...

If its just a simple profile picture, you can avoid most security threats by using a trusted 3rd party like Gravatar(which is what security.se uses). Using a linked image as a "Web Bug" are unavoidable with remote images but apparently a lot of people don't care that Gravatar can track them. Storing an attacker-controlled file locally creates other ...

Anything that restricts the set of possible passwords makes it more vulnerable to a brute force attack. The only reason to forbid some passwords is if the restriction to the password space is compensated by the high propensity of users to pick passwords that can be easily guessed. Let's say you would like passwords with at least 38 bits of entropy (that's ...

Does it really forbid every letter you use in your username? You are right that this is bad as it reduces the pool of potential passwords by quite a considerable amount. Please name and shame so I can stay as far away from this application as possible. A more common scheme is not allowing passwords containing your username, first name or some other piece of ...

You're basically asking, if your object creation through parameterized URL query can be exploited in such a way to load it with an XSS code. The short answer is not unless you plan on using this newly created object for anything. The long answer of course depends on what you plan on doing with this newly created object, will you be sanitizing its properties ...

As mentioned elsewhere on this site (see this and this, your "secret" can be discovered in web server logs and many other means. Using this as a means of access control is known as "security through obscurity", and can be easily discovered. However some less secure sites will use a variation of this theme and use it to protect a session after a user logs ...

Besides the other answers posted, there's the general problem that web browsers and their users generally do not consider URL's to be sensitive information. They are stored in history files, bookmarks, etc. without encryption by the browsers, and users will happily share them via e-mail, instant message, or cloud bookmark/url sharing services, not ...

Hiding and not protecting functionality is not a good security practice. There are indirect ways this functionality can leak, such as: Vulnerabilities in other parts of your web application can lead to arbitrary file access making your index.php file readable. HTML text and JavaScript code can leak the name of the hidden variable or it can hint the type ...

If this is a privileged function that should not be executed by just anyone, then you need to protect your function by also checking the identity of the user (e.g. session id). Furthermore you should make sure that you have a CSRF token, if someone were to send a link to one of your users with that GET request and the user opens it, he might end up ...

This is too broad to answer fully, but I'd start with everything on the OWASP Top Ten. Then I'd go on and review the entire OWASP web site, and move on to the SANS institute's top 25 After you've read those and have a baseline understanding of all the web application threats and vulnerabilities, THEN start Googling "Secure PHP Coding". This was the first ...

A database connection will let the user do pretty much anything he likes to the database, provided he has the access rights. Open a connection straight to the Internet, and the only thing keeping any user from admin account access is the secrecy of the password of the admin account. For the most part, you won't see a database system built with this sort of ...

I'm not sure what exactly you mean. Separation in to layers like application and business logic and data access is not so much about security as it is about maintainability. It's done to make the code useable and be able to do things like change the database you use without having to fully rewrite the application. It does also make security easier as you ...

You can never trust the client, and using a cookie is just that - you are relying on the client (possibly an attacker) sending you accurate information. For this to work properly, you'd need to store this server side. You could store the reset attempt count with the account data, and just reset it to 0 on successful login - workable for smaller sites. For ...

When an external image is "attached" to the comment, then one of these two things occurs, depending on the way your server handles such things: A reference to the URL pointing to the image is kept, and reproduced in the HTML file which is returned to any client browser visiting your site. The image is downloaded by your server, and the clients will receive ...

Not only can they tell your IP, but they could also guess at what kind of browser you're running and what website sent you there (referer header). Yes, the only way to control image privacy is to keep those images hosted on a server whose Privacy Policy you control, and in your case that would include copying the images to your server.