Hot answers tagged

174

Technically slightly, yes. But: It would be security by obscurity, which is a bad idea It does not boost confidence in your product It would be very easy to figure out what does what, it would only take a bit of time Google Translate, you can just use meaningless names, it would still not help much It would make maintenance harder It would make audits very ...


135

I wasn't originally aiming for a self-answer, but after more reading I've come up with what I believe to be a comprehensive answer that also explains why some might still be interested in CSRF protection on REST endpoints. No cookies = No CSRF It really is that simple. Browsers send cookies along with all requests. CSRF attacks depend upon this behavior. ...


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


63

It would not be appreciably more secure. Reverse engineers are often forced to work with systems that do not have any original names intact (production software often strips symbol names), so they get used to dealing with names that have been generated by a computer. An example, taken from Wikipedia, of a snippet of the kind of decompiled C code that is ...


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


53

I'd go with SSL/TLS everywhere (since you control both sides, forcing TLS 1.2 should be feasible). It's relatively simple to use, and you get a lot of security features for free. For example if you don't use SSL, you'll need to worry about replay attacks. If you're worried about performance, make sure session resumption is supported by both the server and ...


52

Your basic approach is valid: generate the JWT when the user logs in, expect subsequent messages to carry the JWT, trust the subject field in the JWT in those subsequent messages if the JWT is valid. But there are several things you should be aware of: As Daisetsu say, you could use a MAC ("alg":"HS256") as MACs are specifically designed to prevent ...


40

This would be impossible. It is fundamental for your app to contain all the instructions necessary to use your API. Anyone with enough skill and time will be able to extract these secrets and create their own client.


36

Not really - all of the built-in functions will still be in English, so it wouldn't take much extra effort to work out what your variables are going to represent. It might slow someone down slightly, but given that people still manage to reverse-engineer code with single character variables all over the place, or which has been run through obfuscators, ...


35

I didn't see this mentioned in the other responses, but you generally should not put secret information (passwords) in GET requests even with SSL, but use POST instead. Why? The URL with the sensitive information will generally be logged at both ends; e.g., in your browsers history list (https://www.example.com?user=me&password=MyPassword) as well as ...


34

HTTP Basic Authentication is not much used in browser-server connections because it involves, on the browser side, a browser-controlled login popup which is invariably ugly. This of course does not apply to server-server connections, where there is no human user to observe any ugliness, but it contributes to a general climate of mistrust and disuse for Basic ...


34

The reality is if other processes can access your process memory or features of your virtual machine, the game is probably over as you're already compromised. If a process has access at this level, it can probably gain other information, such as the initial credentials used to authenticate before obtaining the token or just modifying results to make token ...


30

The service offered by the token is that the server will somehow recognize the token as one of its own. How can the server validate a HMAC-based token ? By recomputing it, using its secret HAMC key and the data over which HMAC operates. If you want your token to be computed over the userID, password, IP and date, then the server must know all that ...


30

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


26

The key used in HMAC is, by definition, symmetric: the same key is used to compute the MAC value, and to verify the MAC value. Digital signature algorithms are asymmetric, which means that the key for verification is distinct from the key used for generation; this "difference" is strong: the key used for generation cannot be recomputed from the key used for ...


26

Looks like you have a pretty good idea what you're doing. The one-time link pattern is pretty common for things like email verification. Typically, you'd store the expiration date in a database and/or use a signed string in the URL which includes the expiry in the string-to-sign. These are just precautions to avoid trusting user input. If you want to be ...


25

The bottom line is that you will need to embed a secret into your app. It is an unfortunate truth that DRM (which is more or less what you are trying to achieve) is impossible. A person with access to your app will always be able to recover the embedded secret, no matter what you do to protect it. That said, there are plenty of things you can do to make ...


25

If the REST API purely returns JSON (and never HTML) then do the HTML escaping client-side, in JavaScript. Whether the client's HTML page uses JQuery templating, or builds up HTML with calls to functions like .html() neither of these by default have XSS protection. One approach is for the client code to explicitly call an escaping function on all untrusted ...


25

I suspect this is a case of someone zealously applying "best practices" that they don't understand. HTTP Verb Tampering Attack The reason this best practice exists is because of the HTTP Verb Tampering Attack. From this article: Many Web server authentication mechanisms use verb-based authentication and access controls. For example, an administrator can ...


24

It’s pretty easy and straightforward to create one’s own client regardless of whether REST or SOAP is used, as long as your Existing Client is available for everyone in the Play Store. Just capture the HTTP traffic from an Android device using Fiddler, and engineer your own client based on the captured traffic. Even HTTPS traffic can be easily decrypted ...


23

I recommend using OAuth. You should definitely read up on it if you're not familiar with it. As a plus, you get to use 3rd party identity providers, so your users can use their Google / Windows Live / etc. accounts for your application, sparing the registration. Even if you want to roll your own authentication framework, I don't recommend using non-expiring ...


22

The jti claim as described here is an optional mechanism for preventing further replay attacks. From the spec: 4.1.7. "jti" (JWT ID) Claim The "jti" (JWT ID) claim provides a unique identifier for the JWT. The identifier value MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be ...


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


21

That is security through obscurity and will delay a dedicated attacker all of five minutes. If you want to confuse an attacker, naming things their opposite or something unrelated would have the same effect. So your "create user" function could be named "BakeCake". Now you can answer yourself how much security that gives you. Actually, this would be more ...


20

With anonymous cookies If you are happy to generate secure tokens which are set as anonymous users' cookies, but not to store them server side then you could simply double submit cookies. e.g. Legitimate user: Anon user navigates to the login page, receives cookie which is sent to the browser. Anon user logs in and the browser sends the cookie as a header ...


19

SSL encrypts and ensures the authenticity of the whole connection, including the requested method and URL. A GET is just as well protected as a POST. When SSL works as intended, an eavesdropper can only see what IP address is connecting to what IP address (and on what port, but it's usually 443), at what time, and how much. If there are multiple virtual ...


17

Mostly you cannot check that this is "your app": reverse engineering works, so whoever has access to your app (e.g. he can download it on his phone) can pluck at its entrails and emulate it with his PC. @Lynks gives you some hints about how this reverse engineering can be made a more frustrating endeavour, but don't fool yourself: if the attacker is ...


17

From a security perspective, no, there's no way to do this. No matter how much obfuscation you put on the code and protocols, the fact is that the code to access the API and the network traffic produced when the API is accessed is in the hands of your users, and they can use whatever reverse-engineering tools they want on it. From a business perspective, ...


16

Yes, there are situations where layers of encryption make sense. Here is one specific example: SSL may be legitimately decrypted by at interim points; it is not always end-to-end: Akamai may decrypt and re-encrypt traffic for which it's providing content delivery. Prolexic wants their clients' SSL keys so that when they're called upon to protect against a ...


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