Hot answers tagged

86

The server time is of little use to an attacker, generally, as long as it is accurate. In fact, what is being revealed is not the current time (after all, barring relativistic physics, time is consistent everywhere) so much as the time skew. Note that, even if you do not explicitly reveal the time, there are often numerous ways to get the local server time ...


84

Has anyone ever thought about doing this? Yes, there was actually a talk about exactly this at defcon 21 (video, slides). Their conclusion was that working with response codes as offensive security can sometimes result in severely slowing down automatic scanners, non-working scanners, and a massive amount of false-positives or false-negatives (it will ...


60

It won't actually slow down an attacker any appreciable amount, but will cause any future developers who work on your platform to be really annoyed at you. It may also cause certain nice features of your HTTP request libraries to not be so nice, as they're operating off of incorrect information. This is a very weak form of security through obscurity. When ...


31

My question is what prevents users from intercepting their regular post form the app (getting the token) and then possibly sending bunch of POST requests (using something like postman or fiddler) to create a large number of fake posts or articles or whatever else the app does. Nothing Does the fact that the traffic to the service will eventually go via ...


29

Checking headers off a list is not the best technique to assert a site's security. Services like securityheaders.io can point you in the right direction but all they do is compare against a list of proposed settings without any context about your application. Consequently, some of the proposals wont't have any impact on the security of an API endpoint that ...


27

As Steffen has said you cannot protect the token from users. I'd just like to add a suggestion for a more general scenario of having a "demo" Api. It sounds like your API doesn't have any stored data and just does calculations on input so this may not be a concern for you, but rather than having the demo token point to your real api, you could point it to ...


22

REST Security and API Security are excellent topics of research. This question and the answers provide good starting points to find great tools and techniques to test these interfaces -- API Security Testing Methodologies If I were you, I'd avoid testing a REST interface or an API's security remotely, or via a black-box technique such as dynamic app ...


20

The main advantage of a refresh token is that it is easier to detect if it is compromised. Consider these two scenarios: A single long-lasting auth token is used. A short duration auth token is used, and a long-lasting refresh token periodically requests a new auth token once the previous one has expired. In scenario 1, if the auth token is compromised it ...


15

If there's no user input used to construct the queries, there's no threat of SQL injection. This is a reasonably good way to go about allowing an Android app to get data from a shared database. The primary thing to think about are denial of service attacks - can one user make repeated calls to the endpoint that bring down the service (and potentially other ...


14

If the transport itself is secured (i.e. https) an attacker can not sniff the data. But it might be logged at the server side and the server might later be compromised or some security leak might cause the log files to be publicly visible. Such log files usually contain the URL and they might contain other lines from the headers like User-Agent, Referer and ...


14

Here is the difference between Implicit Flow and AuthCode Flow: Implicit Flow NOTE: As of April 2019, the Oauth Working Group no longer recommends the use of Implicit Flow for most cases because there are better, more secure ways to accomplish the same things. User navigates to SPA, which redirects user to IdP to sign in. User signs in (and authorizes the ...


14

TLDR; SHA256 is good enough To answer this we need to look at why we salt, hash, and use multiple iterations of the hash, in the first place; Why do we salt? To protect users that have weak password entropy from having their password cracked (e.g. rainbow tables or two users with the same password). This is not an issue because UUID4 will have 122 bits of ...


13

My question is what prevents users from intercepting their regular post form the app Nothing. Does the fact that the traffic to the service will eventually go via TLS make this a non-issue? If you make it for an mobile platform (Android/iOS), that makes it much harder (but not impossible). If you make it for the browser, this doesn't add much ...


12

1. Where to authenticate the user? If it is a user who needs to authenticate, then you need something in your front-end. From your front-end, you can just do a POST to your back-end, with the user credentials. You verify the user credentials, and issue an accesstoken/refreshtoken pair in case the credentials are known. You will ALWAYS have to go via the ...


12

Cookie Based Authentication Pros HttpOnly Flag: Session cookies can be created with the HttpOnly flag which secures the cookies from malicious JavaScript (XSS-Cross-Site Scripting). Secure flag: Session cookies can be created with Secure flag that prevents the cookies transmission over an unencrypted channel. Cons CSRF: Cookies are vulnerable/susceptible ...


12

It is not possible to protect the token because as you noticed yourself the user can simply look what kind of request was sent. Since the demo site is under your control you can though change the demo token whenever you want. As long as you only accept valid tokens and you change the token often enough you will limit misuse of the token. And since the page ...


11

XSSI works by trying to evaluate a JSON response as Javascript and the sequence )]}' prevents this by reliably producing a syntax error. There have been different proposed countermeasures against unwanted script inclusion, but putting an infinite loop (I have seen for(;;) used in Facebook APIs) or producing a syntax error (some Google APIs use )]}' as in ...


11

The reason PKCE is important is that on mobile OS, the OS allows apps to register to handle redirect URIs so a malicious app can register and receive redirects with the authorization code for legitimate apps. This is known as an Authorization Code Interception Attack. Authorization Code Interception Attack This is described by WSO2 here: Since multiple ...


11

"Servlet" sounds like you're already running a complex server there. There's a lot of ways that protocols leak server time. For example, HTTP has a popular header field for creation/modification time, and dynamically generated data would always have the current system time, if used properly. For TLS authentication reasons, you can even binary search to ...


9

Mutual TLS (aka Client Authentication) is a solution to this. As for issuing certs I wouldn't do that. I would take self-signed certs from the client and pin them directly to principals (users) in some manner. I would have a lookup table indexed by both common name and certificate public key to do that. This makes potential problems like cert revocation (...


9

Rather than return a "401 Unauthorized," why not return e.g. "305 Use Proxy," i.e. purposely being confusing. Yes it will confuse an attacker. But for a trained one, it might not be for more than two seconds flat. And status codes are not all that useful, mainly just when brute-forcing file names. Say i have a valid key, and i can observe you returning ...


9

As you may expect it, there is no way to fully protect your api key if it is directly used by a client application. The user can sniff his netowrk (the use of https or of an encrypted channel might still help but is only a matter of time as the user can see the full handshake) or reverse engeneering the software (same here, you can encrypt the api key but ...


9

This write-up Okta has on this subject explains this pretty well IMHO. I believe it's because PKCE is intended for native applications (e.g. Android, iOS, UWP, Electron, etc.) where you leave the security context of your application and go to the browser to authenticate, and rely on the secure return to your application from the browser. You don't ...


8

If you have this Y-problem, it is wrong to return a 404 when the resource does not exist because this helps to enumerate the existing resources. then this means you have this X-problem: Resource enumeration should be prevented. This in turn might affect all resources or unauthenticated resources only. In other words you might be able to mitigate the ...


8

If you can fake the price this way then this is basically due to improper validation of user input. It does not matter if the fake price comes because you've used another API endpoint (spoofing name resolution with manipulating hosts file or DNS) or if you've edited the page in the browser or if you've changed what got submitted to the server by intercepting ...


7

I think the question here should more be answered from a marketing than a security perspective. In general, I would say that Google probably uses a relatively simple API key for usability/accessibility, in order to make it easier for the mass of developers to implement their services (and earn money from that). Amazon probably has more concerns about the ...


7

So, you're asking if you can store the API Key in the App, but also protect it from being stolen? This is not possible. There is a possible solution to make theft more difficult. Use OTP XOR encryption so that the API Key is split into two parts that must be combined. The first part is stored in your application. The second part is downloaded from your ...


7

I don't know anything about Dropbox in particular, but my understanding of API keys from other storage providers like Google Drive, Amazon S3, etc is that they allow users to log in either through their apps, or through 3rd party apps and they want to be able to track which is which. The quote in the question makes it sound like this is about privacy: ...


7

My question is what prevents users from intercepting their regular post from the app (getting the token) and then possibly sending bunch of POST requests (using something like postman or fiddler) to create a large number of fake posts or articles or whatever else the app does. What are some possible ways from protecting from this? You don't. That is, ...


7

First off, if these user IDs are actually sensitive information as you say, do not put them directly in the URL. Why not just make opaque URLs instead and solve the problem before it even occurs? If you remove the relationship between the URL and the user(s), it will be next to impossible to deduce any relationships from a returned status code. For example, ...


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