Tag Info

New answers tagged

12

As @cpast says, the main problem of a single SHA-256 is that it is way too fast. An attacker with an off-the-shelf gaming GPU can try passwords at a rate that is counted in billions per second (American billions, but that's still a lot). Another problem is that there is potential for combining things improperly. SHA-256 is a hash function: it takes one ...


6

sha256 is not designed to hash passwords. To hash passwords, you should prefer to use hash functions created for this usage. You will find all required information below in another question addressing a similar request: Most secure password hash algorithm(s)?. In the above mentioned question, you will learn why general purpose hash functions like sha256 do ...


16

General-purpose hashes have been obsolete for passwords for over a decade. The issue is that they're fast, and passwords have low entropy, meaning brute-force is very easy with any general-purpose hash. You need to use a function which is deliberately slow, like PBKDF2, bcrypt, or scrypt. Crackstation actually explains this if you read the whole page. On the ...


1

If you understand how CSRF mechanism works, you would easily conclude that the answer to your question is YES.


3

Yes, both GET and POST are vulnerable to CSRF. However, RFC 2616 states the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". Therefore, if a website has stuck to the standard and only implements "unsafe" actions as POSTs, then here only POST requests are ...


1

The method; i.e. put, post, delete, request, get etc., of sending data is irrelevant. A CSRF (Cross Site Request Forgery) attack allows for un-trusted content to be injected and processed by the web server.


0

This sounds like a good plan. Some things to consider are: Private keys need to be private. That likely means a secure store with some kind of password/key to unlock the store. Frequently OS or framework support is easiest. HSMs will be a more secure alternative but I'm guessing that they would be overkill in your situation. You need to provide ...


3

There are two main types of issues that can occur with client-side execution: A malicious client can modify their client state and attempt to make the server accept that modified state as valid An unsuspecting user can be tricked into running code in their console by a malicious third-party, something caused Self XSS Malicious clients running ...


0

Javascript, and all other client side technologies, are inherently insecure. You can't keep people from cheating, only make it more difficult.


3

Yes it can be an issue but there are ways for applications to protect against it. Two sides to every internet application. In order to understand internet application security you have to understand the difference between the client and the server. Data which is generated by the client (the browser), must be sanitized and validated before being by the ...


0

The problem with a browser extension approach is that many users would be either unwilling or enable to install it (eg logged in at their place of work they would not be able to install extensions). You also have to securely distribute the extension which is a problem itself. One online banking approach I have seen the bank puts a custom browser bin/exe ...


0

Unless you are undergoing a polygraph examination (in which case you will have already disclosed pertinent answers such as 'have you hacked a system' and are merely being tested on truthfulness of your disclosures) then take the American attitude of anti-self incrimination (the 5th Amendment to the US Constitution). During your interview, simply explain ...


3

What if they entered their email as "></a><script>alert("XSS")</script><a href=" which (might) be rendered by the application as <a href="mailto:"></a><script>alert("XSS")</script><a href="">"></a><script>alert("XSS")</script><a href="</a>. giving rise to a Stored XSS ...


2

To quote directly: Only use inbuilt session management. Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies. What this is saying is that, if you've got a secondary system which doesn't/can't use inbuilt sessions, you shouldn't send that second session token as a ...


4

2FA will decrease the chance that an attacker can steal a complete set of login credentials because, as you point out, the second factor is likely limited by lifetime or a once-use policy. But 2FA will not affect snooping or session hijacking. So, while an attacker may find it more difficult to login as you, they can watch your communication stream and send ...


0

As you have stated yourself: it is slightly more secure because it is limited to a < 30 seconds timeframe, but that really doesn't matter much in the grand scheme of things: it is still very insecure and it will mostly just increase the effort legitimate users will have to put in.


1

I think the security threats come from a few places: Data accessed by IFTTT. An attack can happen in transit, in memory, or in storage (for a security evaluation I'll assume that IFTTT stores all data it accesses). Accounts and devices connected to IFTTT. While you're recipes may not access sensitive data, if IFTTT has access due to mobile app ...


4

This can be a particularly tricky problems. You're approach should match the size of your business (will your solution scale), and the sensitivity of the information. If you look at a company like Trello, they won't change Administrators for you. If I had to guess their reason for this, it is because the risk of them exposing your data doesn't justify ...


0

Yes, you are right, all it does is it moves the issue to another place. There are several ways to protect the password of the Keystore using PBKDF2. Using a password that is needed at start up of the application server(as you mention). Composing the password of PBKDF2 out of 'things' you know about your deployment environment; for example: concatenating ...


1

My suggestion would be to send something to the companies registered address e.g. a code they can read back to you, or a URL to create a new account. I would address the letter to the job title of the previous administrator e.g. "To The Technical Director". This gives it the best possible change of reaching the person performing the duties of the previous ...


1

Note: My answer is on the basis that zzovq.voluumtrk.com is not your own domain, as you mention content is being proxied. This is not clickjacking because the site is proxying your site via their own domain (zzovq.voluumtrk.com). Therefore normal defences such as including the X-Frame-Options header may not work as they could be stripping such a header via ...


4

It looks like someone is trying exploit an SQL injection vulnerability in struts2 in order to perform remote code execution. See http://struts.apache.org/docs/s2-016.html


4

You are not adding much security doing it this way alone: if an attacker can find a fault in your web app, using a reverse proxy alone will not prevent anything. However, the fact that your reverse proxy is the place where the SSL connection is terminated allow you to add other security systems in between the final app and the user: it could be a WAF, an ...


2

Possibly clickjacking Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page. An example: For example, imagine an attacker who builds a web site that has a button ...


1

You haven't mentioned whether you have tried the request with cookies (or other authentication data) withheld. If the request still works without authentication for the same scheme and you've removed caching headers like If-Modified-Since and If-None-Match then it is "A4 – Insecure Direct Object References". If the request works only when you haven't ...


4

Avoiding attacks on your site You need to validate that the string you received is valid. Remember this principle: you must white-list acceptable strings rather than black-list unacceptable ones. Ensure that the string is a syntactically-correct and escaped URL. Escaping the whole URL avoids it containing " or > which could break your site's syntax. ...


1

The web server seems to apply different security control whether the access comes from HTTPS and from HTTP. Most probable is that the designers thought that this file would be accessible only to HTTPS users, and missed the fact that this URL can also be served through HTTP. In your question you refer to: A7 – Missing Function Level Access Control: This ...


1

As @Gumbo has said, CRLF are properly encoded with %0d%0a in the resulting URL, as you may see. If it had set headers as you had passed as parameters, you would have seen those headers separately. You may try different encoding instead, like %E5%98%8A%E5%98%8D :) The ability of attacker to construct arbitrary HTTP responses permits a variety of resulting ...


0

If I include a Forgot Password service, then what's the point of using a password? Because if a user can log into their account with their known password they know that an attacker hasn't used a password reset link and changed their password. Password resets create noise. In logs on the target system (which can sometimes be viewed by the user), and in ...


2

This appears to be some type of what is known as Second Order SQL Injection. Even if Thread 1 writes to a queue instead of to a DB, as the injection does not happen as a direct result of it, sqlmap cannot be used to exploit the vulnerability. Sqlmap looks for error messages in responses or differences in timing (for blind SQL injection) to determine ...


1

I think this is a very complex problem to solve, and any tools that we do have are relatively young. However, I think there are some good options out there, and some people pioneering in this area. I think there are two aspects to your proposed problem: The most obvious is crawling. The tool needs to be able to map out the whole application, including any ...


0

It will be secure in that other people would not be able to access it. However, if they do then you should not run this locally as your own machine could be compromised by a malicious user. However, be aware that the following could still be possible, depending on the CMS: There could be an XSS flaw. If the CMS is displayiing content from your online ...


1

It is really important that you provide viable alternative solutions and not just rely on arguments that it is a bad technical solution. For example, could using a VPN setup be a better choice rather than re-developing the code to use a non-privileged user? Can you generalise the solution? For example, would a VPN solution provide increased and more secure ...


0

Assuming you're running a server locally and putting a local Drupal/WordPress etc. CMS on that local server than sure, you could configure it not to be accessible to the outside world. But, seeing as it sounds like you want to actually have an 'online' website that won't really work. If you want to securely work with a CMS gowenfawr is right just lookup ...


1

If your CMS is listening to 127.0.0.1 ("localhost") and not to any other IP addresses on your system, then yes, no one online will be able to access it. You will be the only one able to access it, while logged into the computer it's running on. It is unusual that this would be what you want, but hey, maybe you just want to use your CMS as a personal ...


0

I would advise against it. Your web application should have a policy that passwords are only ever input, never output. I find that with following this approach, your application will be more secure in general. There is also a further problem of how to give the password to the user. Displaying the password on screen (either in an email or when they register) ...


0

I have the same requests in my log. All those requests came from Kazakhstan. And all requests has no referrer, or refer the same page as request. Also, there is no requests for other static resources, like images, JS- or CSS-resources. As really paranoid, I think, that this work of some type of vulnerability scanner. Possible, it try to detect version of ...


3

That totally depends on your application and its requirements. If your applications needs to verify users' email addresses, then you can send them a randomly generated token (one-time use and valid for a limited time period) for the first-time login, on the email address that they provided during sign-up. And ask them to set their own password after they ...


0

If your generation method has enough length and good character set, it will be more secure than asking the user for password. The problem about this way which makes websites not to use it, is because auto-generated passwords are hard-to-remember and don't offer good user experience.


6

It is a security issue, and tampering with headers, or really, anything that you have on the client side is very easy. You should never trust anything that coming from the client. I would definitively suggest that you have a white list of acceptable values that is enforced on the server side to avoid SQL injections. This list could be generated ...


7

This is not a good idea. An attacker could change the database name, supply an invalid one, or put special chars on the database name and possibly exploit a SQL injection. It's possible to do a lot of damage depending on your setup. You could use server-side sessions, and send only the session token to the user. The database he is connecting to should be ...


2

If all you are passing over is a simple name which identifies a database to use, then I can't see any immediate problems (provided you do some server side validation). I would try to avoid using names that give away more info about the database than needed though (e.g. server addresses, system- or version-info, etc). In fact, it might be better to just use ...


1

It depends on the bank's security in general. Europe is better than the US, but there are stories of forged debits in the UK as well where they only used basic information. If you are worried about routing numbers and account numbers (as leaking a database can be a PR nightmare regardless if the info regards financial information), you could opt for a ...


0

I'm assuming the user logs in or proves who they are, and would not be anonymous and only providing an encryption key for authentication. It seems like it would be best to just periodically POST the answer to the server and store them in a HIPPA compliant way there. StackExchange temporarily stores your answers, so you could look and see how they are doing ...



Top 50 recent answers are included