Hot answers tagged

56

The answers you received on the UX stackexchange are pretty much on point. 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 ...


32

XSS is a form of code injection, i.e. the attacker manages to inject its own malicious code (usually JavaScript) into trusted code (HTML, CSS, JavaScript) provided by the site. It is similar to SQLi in that it is caused by dynamically constructed code, i.e. SQL statements, HTML pages etc. But while there are established techniques to solve SQLi (i.e. use ...


27

Nope. Keyloggers can often also do screen-capturing and mouse-coordinate-logging. So the attacker can still see what image the user selects. Another kind of two-factor authentication for which the user needs two devices (e.g. laptop and phone) would be more secure. Another good alternative is a Yubikey. A kind of device which generates a pseudo-random ...


22

Typically, it's just the last 4 that are shown to the customer, sometimes the first 6. From the PCI DSS 3.4 Standards Never store the personal identification number (PIN) or PIN Block. Be sure to mask PAN whenever it is displayed. The first six and last four digits are the maximum number of digits that may be displayed. This requirement does not ...


21

It seems easy, but is hard First of all, the attack surface is huge. You need to deal with XSS if you want to display user input in HTML anywhere. This is something almost all sites do, unless they are built purely in static HTML. Combine this with that fact that while XSS might seem easy to deal with, it is not. The OWASP XSS prevention cheat sheet is 4 ...


20

I agree with a lot of the answers, but one very important point isn't made: code doesn't magically fix itself, and there is a lot of code out there which is 17 years old. I have seen many companies write clean and safe new code, whilst the application could still be attacked in some of it's older sections. And worst of all: fixing old code is expensive, ...


9

Once the system is infected with malware it is compromised. Anything that is done on that system can be observed so there is no way to allow someone to log in securely from that system just using that system. Period. End of Story. You might come up with some oddball scheme for something the user has to do as part of the login process that the malware doesn'...


7

No confidential data should ever be sent via GET. The data may be leaked or stored by: referers if you link to a different page after a login your server logs which is an issue if these logs are ever available, for example via LFI, wrong server configurations, backups, etc. browser histories which is an issue if multiple people use the same browser - eg ...


7

Yes, anthropologically, humans are stupid. Yes, politically, the incentive structure does not sufficiently penalize vulnerable applications Yes, the process is flawed-- code is written in a hurry; bad/old code is not always thrown away. And, yes, technically, treating and mixing data as code is harder to do by default. But, there's a more positive view ...


7

My set of opinion on security and XSS: Rule of programming: You can't know everything. Sooner or later you are going to make a mistake. Rule of programmer: A programmer works 12h a day: 3 is discussing with other programmers random things, 3 is thinking at other things, 3 is discussing on what it should code, 3 it's programming .... projects are made for ...


6

If you tightly adjust your WAF to your application so that it can fully distinguish valid from invalid input for specific input fields than you should be able to detect attempts to inject persistent XSS through the use of input fields. But, usually WAF are not adapted that tightly to the specific application and in this case only employ some heuristics to ...


6

Because such security issues are not covered during most 3-year education cycles and equivalent studies, and many developers followed such track (including myself). Given how wide the field is, actually 3 years is not even enough to cope with the actual study program.. So things like security are dropped. It is unfortunate, but since some of the new ...


6

As mentioned in the answer to a similar post of yours (SQL injection is 17 years old. Why is it still around?): There is no general fix for SQLi because there is no fix for human stupidity Developers sometimes get lazy or careless and that causes them to not check the application they are developing. Another popular reason is that the developers aren'...


6

The main security argument to disallow copy&pasting of passwords is that the password remains in the users clipboard afterwards. This can lead to accidental exposure of the password in an unrelated context. For example when the user then accidently pastes it into a different input field in a different application (web or otherwise). Another possible ...


5

The reason for the delay is that there has been little change in the Web T10. As stated by Dave Wichers, the Web T10 project lead, on 30 June 2015: Historically, we've produced a new OWASP Top 10 every 3 years because this seems to balance the tempo of change in the AppSec market, all the work everyone does to map their tool/process/other thing to ...


4

I believe it's because many developers learn just enough to get the job done, for some value of "done". They learn how to build SQL code, often from outdated online tutorials, and then when the code "works" to the extent that they can say "I can put stuff in the database, and I can generate the page of results", then they're satisfied. Consider this guy on ...


4

The other answers have pointed to almost all the reasons. But there is something else, which I think is the most dangerous security concern of all. Developers attempt to add more and more features to technologies, and sometimes deviate from the actual purpose of the technology. A little like how a client side scripting language ended up being used for server ...


4

@ThiefMaster's answer does a great job of enumerating the risks of using an externally controlled Content-- which basically fall under the category of executing or displaying arbitrary code and content on a user's browser. I will mainly focus on your last question: How are those risk mitigated? which was unaddressed-- a lot has since changed (in 4 years). ...


4

If you use prepared statements correctly, SQL injection is not possible. "If the original statement template is not derived from external input, SQL injection cannot occur." https://en.m.wikipedia.org/wiki/Prepared_statement Unfortunately people usually don't use prepared statements correctly, if at all. SQL injection would be a thing of the past if ...


4

Depends. It is very common to ensure the session cookie integrity. One way is to create a very random (reasonable long) identifier, another way is to sign the session cookie. It is even a MUST with the stateless systems, where the cookie passes the whole user context (very popular today). So - you can have a cookie containing its signature within (such ...


4

[1] Efficiency: Assuming you issue a new token for each link for every registration attempt, you will end up with a with a number of tokens that you have to keep track for an indefinite amount of times. For practicality terms I would suggest you set a time/date expiration period depending on the nature of your application. [2] Security: In the case of ...


4

The root problem The web was simply not designed to allow secure multi-authorship or rich interaction. Nobody talked about separating content from presentation until the late 1990s. By that point, like the QWERTY keyboard, we were basically stuck for no good reason with an existing system. Nobody wanted to "break the web", so mistakes were copied and ported ...


4

The way a keylogger can defeat 2FA is if the attacker is in the middle and logs in for you. If this happens, you will not see unusual activity, you will see logins exactly when you logged in, but perhaps not from your location (if your account logs that). A captured 2FA code is only useful for a few seconds. What MIGHT happen, is that the 2FA protection ...


3

I think that the point isn't phrased ideally, as a WAF can indeed catch some persistent XSS attacks. But there are at least two problems: persistent XSS attacks do not just happen via web requests, but could happen via a variety of other means, such as email. The vulnerability is really only introduced when data is read from the data storage - eg the db - ...


3

Putting actual information into cookies, as opposed to just storing a session ID and keeping the rest of the information server side can (but does not have to) be problematic. There are two pitfalls you want to avoid: Trusting information in the cookie without server side validation, e.g. accepting a total price of $0.01 just because the cookie says so. ...


3

OSI layers do not care where the check happens, but at which layer the information used in the check reside. If the check is doing whitelisting by IP address only it does not matter where the check is configured, because the decision is always purely based on the IP address, i.e. OSI layer 3. But, depending on the setup and the validation code the check ...


3

Others have touched on the classic issues surrounding systems designed by humans for other humans: The reality is laziness and—sometimes—stupidity coupled with “Why would this happen to me?” arrogance. Oh, how many hours of my life have been spent patching systems and—more importantly—fighting with management to get the time/resources allocated to patch ...


3

Example 1 & 2 This is because your query is applying this clause: '1'='1/*' If you have a comment character inside of your quotes the comment is not respected by the query parser, you would have to exit the quoted context first. 1 is returned as count because that's how many users have that email address. Try this instead for example 1 (the same ...



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