Tag Info

New answers tagged

0

With modern Intel CPU's (and we're talking 5-7 years now...) there is no significant performance hit on the computation involved in an SSL connection. So - from a performance perspective there is no reason not to use SSL everywhere. Another caveat is the vulnerability of mixed content on your page. You should not be referencing HTTP resources on an ...


5

As with all things in security, using HTTPS is a trade-off. You're trading some performance and potentially customer inconvenienace for improved security and other possible benefits (for example google boosting the ratings of SSL enabled sites). Only you can answer whether that's worth it, as only you know what your site does and whether the trade-off is ...


1

FCrDNS should only be required when the end user needs to properly identify itself with a domain or organization, commonly used for email where the from address header should match the PTR of the sending IP (IPv4 or IPv6 Address). Actually Tom, if you notice Google requires IPv6 initiated email connections to have a proper RDNS, so that's out. The fact is ...


2

You just found the issue, you didn't take advantage of the flaw and never intended to do harm (I assume you wouldn't do any harm to your friends). However, every company should be happy if you report the issue to them. Big companies like Twitter or Facebook even pay nice bounties for this. You might check out HackerOne if the company you are talking ...


0

What I can see, is that the main difference is not about "SHA1" but about the certificate chain. See the icons. Both "SHA1" messages are locked with a green icon, but the part about about the identity of the website is different. GOOD: *.mail.live.com . Certification owned by Microsoft, verified by Symantec Class 3. According to digicert.com, no error or ...


0

Why not use two step authentication. Any user performing review should get an authorization code on his/her cell number. After providing that code on browser he/she could perform product review. There should be limit on cell number - one user with specific cell number can review for once.


0

Limiting by IP is too strict in my opinion: As you said there is a problem with dynamic IP. But this alone could maybe solved if you enforce this limit only within a specific time frame because the IP does not change that often. But corporations and institutions often use private IP addresses inside and have few internet gateways. This means all users ...


1

This makes (somewhat) sure that you really are the user associated with the account, you should at least know what email address was used to create the account. Filling the email address automatically could already give an attacker the opportunity to get all the email addresses in the database, just request a new password for every account you can think of. ...


0

CORS was born to lighten the restrictions of the SOP for trusted requests only. But the problems start when you start trusting. Unfortunately there are plenty of online resources claiming there is no risk about it: The bottom line is that if a player has to load content from a different origin, we have to deal with the security concept called ...


3

If the web server you are using is correctly configured, you don't have to worry about the actual uninterpreted ASP / PHP files themselves being served out (unless of course the attacker is exploiting a vulnerability somewhere, as you pointed out). If you're especially concerned about code theft it's probably more useful to think about other, more likely ...


5

You are correct that this is not possible without mis-configuration or security vulnerabilities that allow it. Generally, the most likely culprits when it comes to coughing up application code are commented out code, backup files that have extensions allowing them to be delivered directly to clients without processing, and probably more likely that all ...


5

This crossdomain.xml policy file revokes all protection that the Same Origin Policy provides. I use the crossdomain proof of concept tool, which has a simple interface to test SOP bypasses.


1

As @Philipp states, any URI may have a query string, regardless of the HTTP method (GET, POST, PUT, ...) it is used with. The RFCs do not, in general, explicitly discuss query strings, even when discussing methods like GET where we expect to see them. A rare explicit mention is in RFC 2068: some applications have traditionally used GETs and HEADs ...


1

According to RFC 3986 - Uniform Resource Identifier the query component is allowed for any URI regardless of the used protocol. That means it is not only allowed for any HTTP method (what you call "request type"), but even for any other protocol which uses URIs, like for example ftp.


0

I've been doing some research on mitigating brute force attacks and came across this post. I recently implemented the following approach: In a 24 hour period: On 20 or more failed authentication attempts for a single IP address we require captcha for each subsequent attempt. At 100 failed attempts, we blackhole requests, but give no indication that the ...


1

As of 2015 this is how you prevent your website from sending the Referer header: Just add this to the head section of the web page: <meta name="referrer" content="no-referrer" /> This works both for links and for Ajax requests made by JavaScript code on the page. Other valid meta options include: <meta name="referrer" content="unsafe-url" ...


1

Question 1 Question 1: Are there any obvious security flaws in that scheme (except that the attacker can access the data of all logged-in users)? Proposed scheme: Registration The user digests a password key P from the plain-text password p using SHA 256 The user sends this key over a secure connection to the server The server generates a random ...


2

Well, the server HAS to set this flag on the cookie, if it doesn't, client side scripts such as javascript snippets in a XSS style attack can access the cookie contents. Also, you might want to look at XST(Cross-Site Tracing) which i believe can bypass this flag and allow stealing cookies in some scenarios. From the wiki page for it: Tagging a cookie ...


3

If implemented correctly, HttpOnly prevents an attacker stealing the cookie. However HttpOnly feature can be bypassed in certain versions of some browsers and web servers. Take a look: https://lwn.net/Articles/646891/ https://www.youtube.com/watch?v=jrKOdWPZtAg https://bugzilla.redhat.com/show_bug.cgi?id=1222923 So in summary HttpOnly makes things ...


0

One of the main reasons for hashing passwords and not encrypting them is that people tend to reuse passwords (or minor variants) across many sites. So a password disclosure puts your site at risk and the user across all sites that they've (foolishly) reused that password. A better strategy is to obtain a temporary piece of data for the user that securely ...


0

When HTTP Only flag is set tot true on the server side then there is no other way to steal the cookie using XSS.In modern web browsers like Chrome there is no way to see the cookies using xss because the xss filters are enabled by default. If it is not enabled on the browser then there is also a way to enable the XSS filter in the browser from a server ...


4

But that means that XSS is not for cookie stealing anymore? In short, no, XSS isn't used to steal cookies when this flag is set. The longer answer is that modern browsers support the HttpOnly flag on cookies. This flag can be set when the server sends a Set-Cookie header to the browser to keep document.cookie from getting the contents of cookies. It is ...


-2

The answers about encryption are not wrong, but the approach is wrong. You should not encrypt. You should use a one way hash function. This means that you do a NON-reversible mathematical operation on the password, and store the result. When someone wants to log in, you perform the operation again on the password they supply, and compare it to the result on ...


0

Perhaps the app should use Kerberos to authenticate to the server, as well? E.g. using constrained delegation. Alternatively it could have a SSH key of its own, one that works for all accounts but only from the webapp server's address.


0

There are three issues about that procedure: What if the encryption key is compromised? Are you going to use the same key to encrypt all passwords ? Adobe's system uses a different key so that if a key is compromised only one user would be affected. Storing sensible data such as, in your case, a part of the data used for your cryptography process in ...


0

Based on what you have outlined, your solution seems overly complex and I'm not sure why you wouldn't just encrypt the data rather than hashing it. There may be limitations in what you can store in the remote app that may require encoding the encrypted data (similar to what needs to be done when sending encrypted email). This would eliminate the need to ...


1

You can opt for protection from a scrubbing service by placing your applications behind a packet scrubbing service like Akamai or CloudFlare. These CDN's will take the hit for you normally before it reaches you.


0

A checksum can be provided for the following reasons: to validate that the download is complete; to validate that you are looking at the correct download (later in time); to make sure that a third party download service (proxy, torrent etc) provides you with a valid download. HTTPS helps you with two things: to make sure you connect to the right server ...


1

We have had the same issue here. We decided the quickest and user-friendliest way was to implement a modern Recaptcha ('I am not a Robot') extension. We decided on the Yireo Google Recaptcha extension because it was fast and easy to implement (https://www.yireo.com/software/magento-extensions/recaptcha), but you can also implement your own here ...


63

This is most likely a blind SQL injection, testing whether you're vulnerable to SQL Injection by checking whether your server takes the specified time or more to reply to the request. This is not actually doing any data edit nor exposing anything; it's just checking whether you're vulnerable. It's also worth noting that this specifically targets MySQL ...


9

The data you've posted there appears to be similar to what an attacker might use for finding blind SQL Injection issues. A common technique for finding these issues is to have a conditional test which, if true, causes a timeout or sleep function to run. That way the attacker can tell whether it was successful by obvserving how long it takes the site to ...


9

If the input is not carefully filtered, then that is a vulnerability called Server Side Request Forgery (SSRF). There is even a common weakness enumeration number and page for it. https://cwe.mitre.org/data/definitions/918.html By providing URLs to unexpected hosts or ports, attackers can make it appear that the server is sending the request, possibly ...


5

Well depending on how they've implemented this feature it could indeed be quite dangerous. In addition to to the risks you've mentioned there's also the potential for non-public URLs to be retrieved by the system. For example retrieving http://127.0.0.1 would retrieve localhost. This can be a risk as things like administration panels are commonly deployed ...



Top 50 recent answers are included