New answers tagged

0

It's effectively your rails endpoint that needs to protect itself. It needs to differentiate between your static pages and someone else's malicious page on the internet. I agree that having the rails endpoint check the referrer is a fragile way to authorize access. One possibility is to have the rails endpoint have a route that is not CSRF protected, and ...


1

That the file gets scanned in the browser while downloading. This way you can block malware before it's correctly installed on the system. Most AVs are only able to check for viruses after they've been installed to the system and had the time altering it. This isn't always the case though. Sometimes your browser also leads the downloaded file automatically ...


2

The only safe method for a website to transfer a password to the server is using HTTPS/SSL. If the connection itself is not encrypted, an ManInTheMiddle can modify or strip away any JavaScript sent to the client. So you cannot rely on client side hashing. You cannot setup a secure connection between client and server on your own, because there is no already ...


1

What steps must be followed to send password securely from the user registration page (i.e. client side) to the server over a non encrypted channel (http)? Not to be too blunt, but I think you're trying to solve the wrong problem. The best practice here is that the password should be salted and hashed client-side so that the server never even sees the ...


0

The answer here is that it shouldn't be. The password should be hashed (and salted, and any other algorithms to taste) on the client side, and that hash should be passed to the database. The password should not leave the client-side. If you want to prevent that hash from being intercepted, then HTTPS or similar to encrypt the channel is required.


0

Kudos for trying to present honest reviews - a somewhat unusual take when most business models involving user-submitted reviews tend not to favour such an approach. Regarding what you are doing currently.... You've only told us part of the process here. One common feature of many online sites is that they insist on establishing trust up front before ...


2

Edit: If your website is about crowdsourcing, you probably should have mentioned that in the question right away because that's a very specific topic and different from online vendor scenarios. Yet the solution remains the same. The simplest way would be to hold any verified activities for each user in a database and thus verify if a user really has ...


0

SafeZone protects against keyloggers by sending your keystrokes directly from 'your keyboard' to SafeZone. This way a (malicious) windows application shouldn't be able to intercept it. However, note: that if you're infected with a low-level keylogger, or even one on hardware-level SafeZone can't protect against this because in that case the keylogger ...


4

Anonymous Mode does not protect you from malware. It simply deletes cookies/browsing history/etc. after you close the window. Unlike Anonymous Mode, SafeZone works like a virtual machine whose only function is browsing the web. If you were to encounter any malware while browsing, it would be contained within the SafeZone "VM." As for how it protects ...


3

"More secure" is unconstructive Thinking something is "more secure" often leads to poor decision making. All sorts of things are more secure while being a bad idea. It's more useful to ask "Does this add meaningful security?" and "Is the security gained a reasonable tradeoff between cost and benefit?" Tiers don't add much security Most infosec books ...


1

Well say there was a new, serious vulnerability discovered in ASP.NET 4.0.30319. Attackers can easily find vulnerable servers by using a search engine like Shodan: https://www.shodan.io/search?query=X-AspNet-Version%3A4.0.30319 Hiding the information banners protect you from non-targeted attacks when an attacker just wants some servers to compromise for ...


3

You need an application layer as a filter because most* database systems do not allow permission handling which is fine-grained enough to handle multiple users. Usually* you can create users with different read- and write permissions, but usually* these are designed for up to a few dozen users and do not scale well for thousands or even millions of users. ...


4

If you distinguish between web server, application server and database then you actually mean front end, business logic and back end (storage). This is also called a multi-tier architecture with presentation tier, application tier and data tier. In this case the application server will not simply pass through any requests from the web server but only allow ...


4

I'm generally dubious about the benefits - as @MarkBuffalo says, lots of attackers will try every attack they know on every server they find, whether it's likely to work or not (even to the extent of trying Windows specific attacks against systems reporting that they're running RHEL). However, it's not information you need to give out, so I am generally in ...


6

OWASP defines Information Leakage as a vulnerability, so the debate is really on whether or not the specific version information should be classified as "Information Leakage". As @Oasiscircle mentions, this information can be used as a starting point for attackers who know of specific vulnerabilities associated with specific versions. We know attackers use ...


4

Let's say that today a vulnerability got announced for all Microsoft IIS 7.5 servers with a small range of ASP Net versions. I'm a malicious attacker, and I want to figure out as many servers that I can exploit as possible before sysadmins patch up the vulnerability. Wouldn't it be a much easier problem to figure out if I could ask each individual server ...


5

There are a few reasons that IPv4 addressing is not used in this way: IP addresses are not a foolproof indication of location. IP address blocks are assigned to companies and can be used anywhere they are required. A company in asia may get a block from apnic, but then use part of their allocation in north america Systems get different IP addresses all the ...


2

No, the Same Origin Policy also protects against: Cross domain manipulation in the DOM (e.g. a page manipulating another page from another origin loaded in an IFrame). The response from AJAX requests being read when the origins don't match. Images loaded from other origins from being read into an HTML5 canvas. So my question is: would we really need ...


0

No, it should not be possible to do that! There are several issues raised here: The change password link contains the userid. I'm assuming this is for logged in users to change their passwords - so I'm a bit unsure as to why you're sending out links in that case. You know that they are authorised (or, at least have the ability to log in), so you can ...


1

One good design is to make the Change Password page accessible to logged in users in such a way that only he can change his own password. (users' identity should be bound to something out of their control(e.g sessionid) and shouldn't be sent as a parameter which is guessable and can be tampered by the user to access change password page for others) Your ...


4

As long as you don't execute files contained in that tarball your on the safe side of the fence. As you seem to have realized there is a potential thread which was called zip bomb in the past and contained heavily compressed content which when extracted without size checking will use a lot of space on the disk. // when you say max size you mean the size ...


1

It is worth noting that numerous services exist online that do this sort of thing. Accellion, LiquidFiles, Dropbox, Box.com, and numerous others can grant you this kind of functionality. Depending on volume and complexity, you might even be able to leverage some marketing-oriented online service like salesforce.com or hubspot. There are a zillion things ...


3

You have essentially two issues in your process: providing the update and having it installed. Server Auth Firstly, yes you need to authenticate the server. This means that communication to the server must be done on a secure encrypted channel. Make sure to take the time to understand attacks on SSL so you don't use something that's expired. Ship the ...


2

As pointed out by @王庭茂 and @LieRyan, you need some way to prove that the public key that gets uploaded with the license file actually came from your company and wasn't planted there by an attacker (in your case, someone trying to forge a license file without paying). The solution to this is to have your public key made into a certificate. Looking at your ...


2

You need a trust anchor. In x509 PKI systems (used for TLS, S/MIME email, and code signing, among others), the trust anchor is provided by public certificate authorities. Your public key (your certificate) is signed by the certificate authority, which the user implicitly trusts. To forge a certificate that specified your or your organization's name, an ...


-1

When these keys are ment for other applications to connect with your service read about two/three legged authentication. (OAuth) https://tools.ietf.org/html/rfc5849 (Version 1) There is already a version 2 but I have no experience with version 2


0

You don't know enough to make a call. Given the technology involved, the baseline is it could be very, very bad. To raise it above that you need to test it or look at the code or both.


2

Well first of all its an assumption, so assume away! Your talking about the PHP code's security, so can we ignore the outdated versions of the stack: Linux, Apache, PHP, MySQL. All of which you should be able to pull up a number of exploits for (knowing the version) via Google. We can then talk about the PHP application. The code is going to be as secure as ...


1

Use of long random tokens as secrets to provide access to a file can provide effective security. I'd recommend 128+ bits to make it truly outside the range of randomly guessing. You could probably get away with fewer bits, especially if you rate limit IPs based on bad guesses. E.g., if you had a 64-bit or 80 bit token and a billion such files and were ...


1

These types of questions come up from time to time. Essentially, this is security by obscurity. The fact that it is hard to guess only addresses one type of issue. It does not protect against: Users accidentally sharing the link, bookmarking the link, etc. The user accidentally typing the url into Google or another search engine, resulting in it being ...


2

While it definitely does provide a degree of security, it still leaves you a number of security holes that may or may not matter dependent on the type of application you are developing. For a non-exhaustive list: Content may meant to be limited to a select group of users, what if one of them leaks the URL? URLs with GET parameters are stored in a large ...


0

First and foremost, make sure that the secret token is long enough and changes with every access. Always using the same token is very risky, for reasons the other answers pointed out. When using different tokens, there are still several threats here, which can be (partially) mitigated: HTTP sniffing: If the connection is unencrypted, a person with a wifi ...


0

Agree with everyone else in stating that the first email address is the only valid one. Would also like to point out that it's a bad practice to allow for additional spaces at the end of a logon name. If I understand this correctly you're attempting to make the point of potential similarities in user/customer logons to the system. So in answer to your ...


1

There is definitely a security issue that stems from a provider allowing the registration of almost identical email addresses. But it's not quite the one that your specific examples are testing. And its effects aren't even necessarily limited to users of the email service, but can more broadly impact anyone receiving mail from a user that service. The ...


-3

I develop Web applications for a living, and I can say this. While it may not be a "big" security risk, it certainly is sloppy development to allow someone to register with test@test.com; and/or 'test@test.com '. Simply because the developer did not take the usually minimal time to add input validation. I mean even using plain HTML5, if you used an ...


1

All but the first should be rejected simply because they are not valid email addresses. When you copy&paste them verbatim into your favorite email client they might do what you expect, but the most likely behavior is that it interprets them all the same. So if you want email addresses to uniquely identify users, you should insist on entering one ...


17

Only the first email address is actually a valid address. Of course, email address validation is hard, so trying to implement perfect validation does not make sense. At a maximum, you can approximate validation, and for usability reasons, you should be lenient with your filter. Because of this, you should not base your security on the validity of email ...


33

The one and foremost problem with this approach is that in your example, only the first one is actually a syntactically valid email address. The three others are not. This means that one of the two following options holds: The "email address" is merely a suggestion. The system wants a unique login identifier; email addresses are reasonably good identifier ...


2

I think it's going to be extremely difficult, if not impossible to do this. Think about ALL the places where customer data exists, or can be accessed from: Production SQL servers. Development SQL servers. Backup servers. Production webservers. Development webservers. You probably are already auditing production webservers. But what about development ...


2

If there's a way to access data without an audit log, secure the credentials required to access it that way and audit their access. Software such as Vault is geared toward this. Physical control of an MFA token such as storing it on a YubiKey and then putting that in a safe place with somebody who doesn't control the password would provide you with dual ...


5

No. You want to ensure license file's integrity by using a public key to verify. However, if you let your app receive the public key with the license file, an attacker ( who want to change the license file ) could just change the content, generate a new key to sign the content and replace your key with their key. And your app will use attacker's public key ...


2

See comments - the licence information is signed with the private key, and validated using the public key. In this case, the public key can be 100% public - no-one else should be able to sign data with the private key (as long as that is kept secret), and there is no (known) way to get back to the private key from a public key. Publish it on your website, ...


0

So here's a quick sketch of what I would do here. Assign each user a pin on registration. Make sure it's secret. https://codereview.stackexchange.com/questions/61338/generate-random-numbers-without-repetitions Should give you a good way to do this with no repeats. Be sure to pick a sufficiently large number of digits! Have a page with boxes for the ...


0

Ok, here is my opinion. Using Keepass(or any password manager) you could generate a random password like this "CslmHD5Rh6" This is a fairly secure password. According to grc haystack the chances of breaking this password would be 1 in 853,058,371,866,181,866. The only way to break this would be with the hash of the password which if they were able to get the ...


0

Yes, although preventing the application from working in different tabs in incidental. There's a class of web application vulnerabilities called "business logic flaws". These are particularly prevalent when there's a multi-step process to be followed. By giving a user a token, which is passed page to page, and is changed at each step ensures that users ...


30

HEAD is not dangerous in itself, and it does have legitimate uses. The problem is with Java EE. It has a way to set security constraints using web.xml files - but those are only applied to GET and POST, not to HEAD. This means that it is can be possible to bypass authentication using HEAD. There is more information about this and other issues in this paper ...


-2

You can add a massive list of public usernames to the database and do not let the users choose them and reply with a general error. In this way, an attacker can not distinguish between a valid an invalid user. The disadvantage would be: 1- limiting the users to choose their deliberate username 2- Decrease the performance by adding a new query in the fake ...


3

Scrape Artist here. You can't stop me no matter who you are There is no reliable way to do it. You can only make it harder. The harder you make it, the harder you make it for legitimate users. I write web scrapers for fun, and not only have I bypassed all of the above ideas by tim, but I can do it quickly. From my perspective, anything you introduce to ...


4

As well as the excellent points in Tim's answer, there are a couple more options Complain to their ISP If scraping your site is a violation of your terms & conditions, then if you complain to the ISPs of scrapers you have identified from their logs, they will generally tell them to stop doing it. Live with it Try to quantify the damage the scraping ...


18

You can't really prevent it if the data is publicly available. But that doesn't mean that you have to make it extra easy to scrape the data either. Preventing Enumeration By exposing internal, ordered ids you make it extra easy to scrape all products. If you changed it to either product name or a random id, an attacker couldn't retrieve all the data with ...



Top 50 recent answers are included