Tag Info

Hot answers tagged

17

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 ...


14

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 ...


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 ...


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. ...


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 ...


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 ...


4

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 kept to the standard and only implements "unsafe" actions as POSTs, then here only POST requests are ...


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 ...


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 ...


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 ...


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

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 ...


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 ...


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 ...


2

GET and POST can both be vulnerable to CSRF unless the server puts a strong Anti-CSRF mechanism in place, the server cant rely on the browser to prevent cross-domain requests. As for PUT requests, there is a slight difference, theoretically it is vulnerable too, however, it requires the circumstances to be more conducive. Here is why: While GET and POST ...


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.


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 ...


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 ...


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 ...


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 ...


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 ...


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 ...


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 ...



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