Hot answers tagged

85

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


83

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


32

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


29

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


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


23

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


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


16

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


16

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


15

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


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


13

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

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

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

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


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


10

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

API keys are public, by intent. They are an authorisation mechanism, not an authentication mechanism (this is mentioned in your links). It does not matter how they are generated but it matters how they are handled. In other words: "anyone with this key can enter". So, you use API keys when you want to authorise and do not need to authenticate. You use ...


8

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


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

Yes, you should absolutely hash your API keys. In effect, they are your passwords and should be treated as such. And note that's hashed - not encrypted. You never need to decrypt the API keys, hence you should not be able to. As saghaulor says, you need to make sure you use a version 4 UUID (a random one, that is) and that you use a cryptographically secure ...


8

The accepted answer is conflating session based authentication - where a session is maintained in backend database and is stateful with cookies, which are a transport mechanism and so the pros and cons are flawed. As to whether an auth token should be stored in a cookie or a header, that depends on the client. If the client is another REST api, then passing ...


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


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