469

There is no general fix for SQLi because there is no fix for human stupidity. There are established techniques which are easy to use and which fix the problems (especially parameter binding) but one still has to use these techniques. And many developers are simply not aware of security problems. Most care that the application works at all and don't care ...


345

Do I need to verify the user for every single page? Absolutely. Not only every page, but every request to a privileged resource, e.g POST request to update data, delete, view, etc, etc. It is not just about viewing the pages, it is about controlling who can do what on your system. It sounds like your entire authentication and permissions system is broken ...


278

Because it's not a problem. When was the last time a company with a SQL injection vulnerability got hauled up in court, and slapped with a big fine for being reckless with user data, and the directors' warned, fined or locked up for negligence? When was the last time a company lost a big contract because their company website login page didn't validate ...


259

There is no substantial security benefit to disallowing pasted passwords; on the contrary it is likely to weaken security by discouraging the use of password managers to generate and autofill randomized passwords. While some password managers are capable of overriding pasting restrictions, the point still stands that users should not be forced to type their ...


252

Yup! If they are able to retrieve the password from the database, then they are clearly not following password storage best-practices. OWASP provides a good guide for how to do it properly: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet Here's some ammunition you could use in that letter: You want me (the legal guardian of my child) to sign ...


222

Nothing prevents ads from reading your passwords. Ads (or any other script like analytics or JavaScript libraries) have access to the main JavaScript scope, and are able to read a lot of sensitive stuff: financial information, passwords, CSRF tokens, etc. Well, unless they're being loaded in a sandboxed iframe. Loading an ad in a sandboxed iframe will add ...


204

According to Google, the difference is with handling referrer information when clicking on an ad. After a note from AviD and with the help of Xander we conducted some tests and here are the results 1. Clicking on an ad: https://google.com : Google will take you to an HTTP redirection page where they'd append your search query to the referrer information. ...


174

Technically slightly, yes. But: It would be security by obscurity, which is a bad idea It does not boost confidence in your product It would be very easy to figure out what does what, it would only take a bit of time Google Translate, you can just use meaningless names, it would still not help much It would make maintenance harder It would make audits very ...


170

I wasn't originally aiming for a self-answer, but after more reading I've come up with what I believe to be a comprehensive answer that also explains why some might still be interested in CSRF protection on REST endpoints. No cookies = No CSRF It really is that simple. Browsers send cookies along with all requests. CSRF attacks depend upon this behavior. ...


164

The concept is "reducing the threat surface". If there is an expectation that no connections will be made from a certain geographic area, then it makes sense to block that area, because, by definition, it is not legitimate. In theory. (For a health provider, it's a weird choice since customers might want to manage their health while traveling, but this is a ...


160

Most of the details in your question are irrelevant. That the ID is stored in a HTML id attribute, the developer tools, that you are using jQuery... None of that really matters. The only thing that matters is that you have an endpoint on your server called insert.php. An attacker can send any request they want to that endpoint, regardless of what your ...


149

There's no way to be 100% sure if you don't have access to the server, so it's about guessing. Here are some clues: File extensions: login.php is most likely a PHP script. HTTP headers: they may leak some information about the language which is running on the server, and some additional details like the version: X-Powered-By: PHP/7.0.0 means that the page ...


137

Does it make the site any more secure? No, it doesn't alter anything other than your ability to conveniently save items from a page. Using a browser's developer mode, turning off JS, overriding this with a different script that disables that pop-up, or just grabbing data off the wire after stripping the SSL will all work. Is it a good general practice? ...


137

This would store the login link with password and username in the browsers history. It could also be accidentally be captured by things like firewall logs, that wouldn't capture post variables.


137

Yes. Any attack which has as a goal to deny the normal usage of a service by legitimate users is by definition a DoS (Denial of Service).


131

Is there any standard defense technique against it? As outlined in the other answers, bit errors when querying domain names may not be a realistic threat to your web application. But assuming they are, then Subresource Integrity (SRI) helps. With SRI you're specifying a hash of the resource you're loading in an integrity attribute, like so: <script ...


126

Definitely problematic - and worth reporting. If the HTTPS is properly protected with HSTS and preloading, then threat actors observing the traffic wouldn't be able to see the GET contents. But since HSTS is still somewhat rare (and if they're putting plaintext passwords in a GET, they're probably not aware of other best practices like HSTS), the ...


126

... that could be useful in an attack but is normally not available to the attacker Knowledge of invalid input characters are useful but can easily be found by the attacker with just a few tries. Thus this information is not really secret and keeping all users unaware of what exactly went wrong does not actually deter attackers, it only keeps innocent users ...


125

TLS provides three things: Confidentiality: that nobody can see the traffic between you and facebook.com (including the guy at the next table at Starbucks, your ISP, some sketchy network equipment in the datacentre COUGH NSA, nobody). Integrity: that nobody is modifying the messages as they travel between you and facebook.com (this is separate from ...


120

This should be reported right away. There is a multitude of possible attacks which could result in compromise of user accounts. The password shown as a GET parameter is not only a vulnerability according to OWASP, there are many ways those could be abused. Common vulnerabilities allow the theft of protected passwords through attack vectors such as SQL ...


120

Assuming that people trust your site, abusing redirections like this can help avoid spam filters or other automated filtering on forums/comment forms/etc. by appearing to link to pages on your site. Very few people will click on a link to https://evilphishingsite.example.com, but they might click on https://catphotos.example.com?redirect=https://...


119

SQL injection is still around because the software world still doesn't understand that programmatic generation of tree-structured values (like queries or markup) should be done by constructing syntax trees as first-class objects, not by concatenating strings that represent fragments of a language. There has been a bit of progress in recent years with the ...


117

This sounds very much like an "Administrator" account, which typically otherwise has unlimited access to the things that it's the administrator of. The security implications of an admin account are pretty well-understood, as are the best practices. I won't go in to all the details, but your implementation breaks with best-practice on one key feature: ...


117

Quite obviously, if they can display your password, then they are storing your password somehow. They might cache your password on the client-side when you log in (for unjustifiable reasons, like session management), but more likely their password database is in clear text. Either way, it's stored and it should not be. And it looks like they are running a ...


113

Many people have looked at the reasons not to allow name changes from both a security and a community standpoint. However, there are plenty of legitimate reasons to allow username changes, even if the username is separate from the display name, for example: Someone has changed their real life name or the name by which they'd prefer to be called, due to ...


113

You can't. To securely send information over an unsecure channel, you need encryption. Symmetric encryption is out, because you would first need to transport the key, which you can't do securely over an unsecure channel[*]. That leaves you with public key cryptography. You could of course roll your own, but you don't want to be a Dave, so that's out, ...


110

From a security perspective, you need to revalidate everything on the server. This will always be the case, no matter how pretty and advanced HTML5 features become. You simply can not trust the client. You have no idea if it will follow the HTML5 rules or not. You don't even know if it is a browser. So should you validate the whole form with your own JS ...


104

When the server sends its certificate to the client, it actually sends a certificate chain so that the client finds it easier to validate the server certificate (the client is not required to use exactly that chain, but, in practice, most client will use the chain and none other). This is described in the SSL/TLS standard, section 7.4.2, with, in particular, ...


95

Below are the things an attacker can do if there is XSS vulnerability. Ad-Jacking - If you manage to get stored XSS on a website, just inject your ads in it to make money ;) Click-Jacking - You can create a hidden overlay on a page to hijack clicks of the victim to perform malicious actions. Session Hijacking - HTTP cookies can be accessed ...


Only top voted, non community-wiki answers of a minimum length are eligible