New answers tagged

2

If it is a secure CAPTCHA, the AJAX message will send the user's input to a server. The server will validate the input and return a token. The token will then be inserted into the form by the Javascript. When the form is submitted, the server will validate the token with the CAPTCHA service (this could be a web service call or signature validation). So the ...


1

If the validation (i.e. cheching that the user input matches the text on the CAPTCHA) is done client side, nothing is stopping you from bypassing it. You dont even have to read the code - just look at the HTTP request the AJAX send and copy it. This can be done with the developer tool in any browser. A very basic rule for web security is to never trust the ...


3

Thanks to comments from @Anders (thx!), I'm unsure if the password generator is a shared service or a personal authentication token like digipass or SecureID. Password generator is a shared service In this situation, Alice can only get the signed response H(R,K) by proving to the password generator that she is Alice by presenting her PIN. If Alice knew K, ...


1

Depends how you set it up. If you allow Cross Origin Requests from any domain, then an attacker who finds the image URLs can do anything you can do within your Javascript application - the security is exactly the same as what you have. If you restrict the requests to your specific application server, they shouldn't be able to do anything, just as you can't ...


4

It's a false positive. In both cases, the scanner only searched for "root:", assuming it is part of a passwd file. The line that is found is: root:function(a){return a===o} This is obviously not from a passwd file. It is also very unlikely that any server-side vulnerability exists in a request for a jQuery file, generally they are static files that are ...


3

No, JQuery is a client-side technology, which is really a wrapper for JavaScript for use within a web-browser only JavaScript doesn't have the capability to run OS commands when invoked by a browser, unless security settings are lowered within Internet Explorer. And JQuery cannot provide any additional functionality that circumvents this. This appears to ...


0

AFAIK setting the exception in each users browser is the only way to get rid of that message when using a self-signed certificate. But: If your company has a wildcard certificate you could define a sub domain, that is just accessible in local net. If your company doesn't have the wildcard certificate, you could still create the sub-domain, acquire a free ...


3

I don't think there is a risk for an open redirect vulnerability, since anything after the ? will be interpreted as query parameters and not a part of the path. But you should change your code anyway, since you do not make sure that the param is actually URL-encoded. Do this with urlencode(): header('Location: ../page.php?param='.urlencode($param)); ...


-1

Short answer: Yes. Long answer: Yes, but it depends. We don't have a page.php code so we can only guess what that page does in the background. Still, any parameter sent either through POST or GET (or any other request for that matter) is allowed to be edited by end-used. So manipulation is of course possible. Read more about POST (HTTP) and HTTP if you want ...


2

The only time I've ever seen anything similar to this is in Dovecot (IMAP email server) where you can optionally configure it to log a hash of the password attempted for troubleshooting/debugging purposes. However, even with Dovecot (which is an implementation I would trust more than what yours appears to be), it is only something I would enable temporarily ...


2

I can't see any security claims to the application to store the clients inputs. Also, the "ciphertext" seems to be reversible (instead of a hash). It's a bad practice.


1

usually a user table provides the relational association to content in the actual database. eg user:jon_smith posted this blog post The user table is also the logical place to store login credentials. The problem/question is not 'why is a database storing login credentials', but rather 'why arent people storing hashed values of passwords and comparing the ...


0

So why do we even use full-power database software and SQL queries to handle the pretty limited needs of username & password authentication at all?. Why aren't there limited-purpose database applications specifically aimed at just doing what a password database needs to do, vs. using general-purpose applications that leave lots of room for SQL ...


2

I think that onetimesecret.com it's a very useful service, and it fits your needs. Of course, you should share the onetimesecret password by a different channel in order to increase the security and avoid the case of compromising the sensitive information if someone has access to the email account. I have dealt with these situations before and, depending on ...


1

Where I work we have a solution that will automatically detect sensitive information and replace the content with a link to a secured server. The company that sells this makes a business out of it so this isn't a crazy idea. As long as you make the links impossible to guess (long crypto-secure random strings.) The solution we use actually requires the ...


1

There already is a solution for encrypting email: It's called PGP and there are plugins available for most email programs on most operating systems. Its main problem in the real world is that you need the public key of anyone you are going to send an email to, but when you are using it internally you can fix that by setting up a keyserver on your company ...


1

Another angle to symcbean's answer. The whole situation seems rather simplified. Who should take care of what can be queried and what can't? The underliyng DB (using special tables for user storage), the backend of the web application server or even a WAF? What about queries including LIKE statements (i.e. PasswordHash like 'a%', you can see where this is ...


1

You shouldn't show exceptions to users, and it does have a slight impact on security. I'm assuming that you disabled exceptions, and are now worried about the data that is leaked via the screenshot: Leaked Username Usernames aren't generally considered sensitive information. You may still want to keep it secret as defense in depth, to make some attacks ...


0

Generally, those errors are really useful when an attacker is trying to compromise the site. In your case it isn't something fancy, the only attack vector I see is brute-force/dictionary attack, since the error exposed your username.


-2

Mostly you can follow OWASP testing guideline. There plenty of companies help open source security testing. One of the example SecureLayer7, try free open source pentest program.


1

This isn't a security issue. A 404 status is intended to inform your visitor that they have requested a resource that the server does not know about. It's very reasonable to include some help in the response. For example, many servers offer search functionality on their 404 page. If you can offer useful suggestions, you are only helping. (Of course, offering ...


7

I am currently running my website in shared hosting, and I am not able to register TLS/SSL for my website. There is no reasonable alternative to TLS, and trying to re-create it on your own is certainly doomed. Never roll your own crypto. If your shared host doesn't support TLS, then find one that does, or else accept that your site is insecure. ...


1

People who say that are confused. You need to not blindly trust data stored in cookies for important operations, but storing non-confidential (and the username is not confidential) information in a cookie for convenience is fine. Just don't use it for security decisions without validating it first. So, storing the username in a cookie to say "Welcome ...


3

I think the best answer here is to treat the necessary activity as a 301 (permanent) redirect. If you can anticipate misspellings and common issues and catch those in your webserver configuration (whether Apache, Nginx, or IIS), the entire activity should be completely transparent to the user. In your web application you could add some additional handling ...


0

Suggesting an "actual" URL would only be a security risk if it (and the source HTML - "view source") identified the backend technology (CMS etc.) and whether the system/CMS had any security flaws. For example, if I ran a WordPress site and saw the traditional URL formats of http://example.com/2016/05/20/my-article and the source code contained the ...


0

Given that the vulnerable version is 0.0.7 and the current version is still 0.0.7 there is probably no fix, at least none from the vendor. Looks like abandoned software.


5

There's a big gap between "does not require" and "implemented by the lowest bidder". why do we even use full-power database software and SQL queries Because if you're already running a SQL database for your transactional data, implementing a second technology stack with appropriately trained development and support staff for a very specific function is ...


2

Short answer is: You can't. All your server see is what the computer at the library sends. What programs or processes on that computer that generated the data is impossible for you to know. From the servers perspective, it might as well have been a pidgeon with a telegraph as your legitimate user. The fact that the user entered a password does not mitigate ...


1

There really is no way to be validate the input if the user's computer is compromised. There are just too many variables. When your browser submits a form it looks something like this before it's encrypted and sent to the server: POST /login.php HTTP/1.1 Host: www.example.com User-Agent: mycoolbrowser Content-Length: 34 Content-Type: ...


1

In whatever script you use to determine the URLs to offer as suggestions, filter out any admin URLs.


13

However, it led me to wonder if this is considered bad practice, as the server might expose URL's the admin of the website might not want to show publicly. This suggests that the feature is implemented by checking a list of all possible valid URLs (a list the server may not even have or be easily able to get), to include non-public ones, and comparing ...


2

Here's is one approach I've used in this situation: path.normalize() handles all . and .., so you can be sure that if either one is present, it will be at the front of the path. Remove any ../../ from the front of your path. So: var safeSuffix = path.normalize(unsafeSuffix).replace(/^(\.\.[\/\\])+/, ''); var safeJoin = path.join(basePath, safeSuffix); ...


62

If Bob is trying to type products and mistypes product, he already knows there's a URL in the website for products and so you're not telling him anything he doesn't know. If you don't suggest URLs that shouldn't be public, you won't have any issues. Why use a 404 message though, and not do an immediate redirect?


12

I would say that keeping a URL secret is not really the best security practise. You may have some links, whether it's hidden, or generated by Javascript, that will show the admin URL or whatever to anyone who takes a look at it. This is even more true for SPA (Single Page Application) applications I think. I don't think there is any point of hiding URLs of ...


0

This isn't generally a serious concern unless your usernames are email address, which would permit the spamming or phishing of your users. (Or also potentially if you provide a messaging API.) That said, if you feel like the underlying username needs to be a secret: Let new users choose a display name, but don't allow them to choose their underlying ...


0

If you only want to read additional data from the token (like JWT), it is no security threat. Since this part of the token is not even encrypted. If you want to expose some secret keys by hardcoding them or getting them from a web server to change and create a new token, that might be a subject of XSS and so on for example.


-4

Well, the first thing I have to say is what I say to just about anyone asking username/password questions: stop that. Use OpenID and get out of the username/password business. Secondly, usernames should be looked at as a hash collision mitigation, not as security -- i.e, two people with the same password. From a security POV, you should consider the ...


1

There are good answers from @SilverlightFox and @MaxTheBackspace. I just want to make one thing clear again: It should not be possible by default at any point in the application to let users enumerate a (likely) global unique identifier like an email address. Not even ONCE. Not with IP address monitoring and rate limiting and a CAPTCHA in Klingon language ...


3

Allowing a user (or an attacker) to find out whether usernames exist or not is known as a "username enumeration" vulnerability. This is summed up well here: As an attacker if I can use your login or forgotten password page to narrow my list from 10000 targets to 1000 targets, I will. You can add "sign-up page" to that list. This aids an attacker in ...


0

Enumerating usernames is a threat because the combination of username + password will give an attacker access to the account/system. How much of a threat that is depends on your system. For example, in a forum where the username is anyway attached to every post, that threat is very low. If you enforce strong passwords, it reduces the threat. In your ...


0

White-listing the characters is always the best practice instead of black-listing special characters. I had seen the same thing with one of the apps I was assessing. So, I found an input parameter which showed in response at three different places. One of which was inside " " in a-tags. No wonder, XSS was easy there. And yes, already mentioned, many of the ...


0

From a user interface / usability perspective, if I've already taken 3 steps (email, phone/ recaptcha), then that reduces the likelyhood of a machine attack, and any further roadblocks will reduce the number of people who want to sign up but give up in frustration. I personally don't mind at all if I try to choose MarkyMark (No, I'm not the rapper), and if ...


9

When a user tries to log in, he or she enters their username. When registering, you are told if a username is taken or not. If you find a taken username, you can try to log in with it and possibly hack it. Solution which is also another problem: If they had to log in with an email, the knowledge if a username is taken won't help - you log in with an email ...


0

It may be a better practice for the login process work with an email and not a username. If you need to have a username by not making it a piece of authentication an attacker can no longer use the username availability check as a malicious tool. At this point the username is just vanity and public facing identity. I know in a comment you stated you wanted ...


18

The alternative to allowing multiple users to have the same user name is far worse! Really what happens with that system User requests a new password You now have to check passwords to make sure no collisions happen The user can use this to brute force other accounts That's bad. So you need to prevent multiple users from having the same username. You do ...


39

This source says that it is almost impossible to avoid user enumeration in this situation and delaying an attacker is the best you can do: If you are a developer you might be wondering how you can protect your site against this kind of attack. Well, although it's virtually impossible to make an account signup facility immune to username enumeration, it ...


0

You might consider it safe to use FTP web based client, when : You consider connection between client and FTP server as safe when you are fine with ftp sniffing vulnerabilities (for example you connect over trusted connection, like VPN or local network and you trust there are no sniffers on the way and no any device on the way is compromised - what might ...


2

It does provide a security risk, though it may not be a huge one. What that shows is actual code, which reveals: The language your backend uses (at least I hope that's your backend code - if you're doing a database query on the client side, you'd be revealing far too much information to them), and possibly some of the libraries that you're using. ...


6

Any information about the internals of a system or application helps an attacker craft a specific attack. For instance, that error message includes table names, which means it becomes far easier to craft a SQLi attack. In addition, with detailed error messages, I could try to trigger different errors to map out the function of the backend, and even find ...


71

Yes, you should hash your passwords. Storing passwords in plaintext is not acceptable. No, it does not affect the amount of traffic your site require. The hashing should be done server side, so it does not affect what is transmitten from the client. Hashing the passwords protect them from theft once they are stored in your database. To protect them from ...



Top 50 recent answers are included