Timeline for Protect API from being tampered?
Current License: CC BY-SA 4.0
24 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 3, 2020 at 10:29 | comment | added | Neil | Single quotes are not JSON. They are accepted by many parsers, but it's not part of the standard. Date/time fields (if they relate to the same entity), should be in ISO8601 format (yy-MM-ddThh:mm:ss.fffZ) which means it's easy to create/parse with standard libraries. | |
| Jun 2, 2020 at 20:58 | comment | added | Ryan1729 | @AskarKalykov As I mentioned before, the point at which that starts happening is after 9 quadrillion. Specifically at 9,007,199,254,740,992. See jsfiddle.net/koe3fsh1 So, just never assign a user an id that is not between 0 and 9007199254740991, and you can do a dead simple server-side check to see if the id is within that range and reject anything outside of it. (Make sure you handle NaNs correctly though.) Then you can drop any fractional part and use that as the ID, since a user ID should not be an access key. | |
| Jun 2, 2020 at 20:41 | comment | added | Askar Kalykov | @Ryan1729 please look at the following fiddle to understand what I am talking about: jsfiddle.net/4ez675uf If you are going to receive json from backend, you wouldn't even know there was a problem. | |
| Jun 2, 2020 at 19:21 | comment | added | Ryan1729 | If we were talking about single precision floats then sure, having only around 16 million possible IDs makes assigning them non-sequentially difficult, and theoretically you might run out, but that isn't an issue with doubles specifically. | |
| Jun 2, 2020 at 19:18 | comment | added | Ryan1729 | @AskarKalykov 2^53 is over 9 quadrillion. You would have more than enough distinguishable IDs for anything reasonable. You just don't assign any users any IDs outside the integer-safe range. So I'm not sure what you mean by "precision of these ids as doubles fell above integer numbers". You mean the doubles are more precise than needed? Are you worried about bugs arising from fractional doubles appearing somehow? | |
| Jun 2, 2020 at 18:15 | answer | added | Garandy | timeline score: 0 | |
| Jun 2, 2020 at 16:20 | comment | added | Askar Kalykov | @Ryan1729 you won't do any math, but you almost certainly want to pass ids around, and would want to pass proper ids. It would be not so great if clients would start receiving 404 or 403 for legitimate requests just because backend devs decided to use offsets for identificators and precision of these ids as doubles fell above integer numbers. | |
| Jun 2, 2020 at 15:50 | comment | added | Ryan1729 | @AskarKalykov Given that you aren't doing math on IDs inside your application, (I don't know why you would,) that imprecision is very unlikely to come up in practice. You would have almost 2^53 ids available, and that's just the positive integer ones. | |
| Jun 2, 2020 at 9:45 | answer | added | Tom | timeline score: 2 | |
| Jun 2, 2020 at 7:00 | comment | added | Askar Kalykov | To add to previous comments, another reason not to use numeric ids is that numbers in JS are doubles, thus imprecise for big values. | |
| Jun 1, 2020 at 21:07 | comment | added | WoJ | Not security related, but use the ISO format for the timestamp (or epoch). This will save a lot of headache later. Also, use a good, complete library to manipulate this time (for instance the native Python handing of time is horrendous (beurk), fortunately there is arrow, pendulum, dolorean) | |
| Jun 1, 2020 at 17:57 | answer | added | Oleg V. Volkov | timeline score: 11 | |
| Jun 1, 2020 at 14:36 | answer | added | Barker1889 | timeline score: 2 | |
| Jun 1, 2020 at 13:08 | comment | added | stefan | @vidarlo maybe it's my limited imagination, but I can't see scenarios where user enumeration from the outside is a good thing. Sure, internally you have a db with all the users and that might be necessary to use, but externally, I would argue that it's almost always a flaw. | |
| Jun 1, 2020 at 10:51 | answer | added | Pedro | timeline score: 2 | |
| Jun 1, 2020 at 9:47 | comment | added | vidarlo | @stefan this is only relevant if user enumeration is a threat. In a lot of scenarios it's not. | |
| Jun 1, 2020 at 6:22 | comment | added | stefan | Please don't use numerical IDs. Especially not if consecutive. You should not build a system where the users can simply be enumerated. Use random strings instead. If I'm user 55, who's user 54? If I'm user abfkg-4remq, then most likely abfkg-4remr won't even be a user, so as an attacker, I can't easily identify all user IDs | |
| Jun 1, 2020 at 4:22 | answer | added | ian | timeline score: 1 | |
| Jun 1, 2020 at 3:39 | history | became hot network question | |||
| Jun 1, 2020 at 0:00 | history | tweeted | twitter.com/StackSecurity/status/1267244623526801411 | ||
| May 31, 2020 at 19:52 | answer | added | Lukas | timeline score: 13 | |
| May 31, 2020 at 19:51 | vote | accept | VladiC4T | ||
| May 31, 2020 at 19:41 | answer | added | vidarlo | timeline score: 51 | |
| May 31, 2020 at 19:35 | history | asked | VladiC4T | CC BY-SA 4.0 |