Hot answers tagged

140

TL,DR: Don't. (My-)SQL permissions are pretty fine-grained, so I'd wager there shouldn't be any obvious security issues Even with permission on the record level, it does scale easy. If a user has irrestricted SELECT on a table, they can select any record on that table, even those not belonging to them. A salary table would be a bad one. If any user has ...


97

I think you are very confused about what both CORS and SOP do... neither is relevant to these attacks at all. There are lots of ways to bypass client-side validation. HTTP is just a stream of bytes, and in HTTP 1.x they're even human-readable text (at least for the headers). This makes it trivial to forge or manipulate requests. Here's a subset of ways to do ...


87

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


67

Interesting question. In theory, this can be done securely. MS-SQL can secure the connection with encryption, authenticate the user, and provides fine-grained permissions and other security features like auditing. In fact, it used to be common in intranet environments that thick clients would access a database directly, so the database security controls ...


61

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


57

I've built both RESTful interfaces and provided customers with direct SQL access. The problem here is that the question is fundamentally flawed: Lots of the work backend developers do is providing CRUD access to customers via HTTP, essentially mapping data from and to the internal database. This is not, in my experience, a significant portion of ...


51

What if the attacker decides to tamper the "from:id" such that it could send arbitrary messages to anyone from any user? Create a session, and use the session identifier as identifier, not the user ID directly. E.g. let user send credentials, and upon successful validation, return a (short lived) session handle, that can be used in future messages. ...


41

As specified, the problem is completely impossible. You can not, and should not attempt to, make a program - much less a script - do something its user can't see. There are many ways the attacker could break this. They could just read and analyze your python scripts (even if compiled, .pyc is easy to decompile). They could debug the program as it runs. They ...


37

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


34

Performance You say that performance should be "way better", except that now you've just given malicious actors complete authority to wreck the performance of your DB. Of course, they have to authenticate, but the "malicious" actor could also be a "naive, incompetent" legitimate user. What are you going to do when users start running outer joins on all ...


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


28

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


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


26

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


25

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


23

Maybe a very short answer will help as well. I never thought about it much, I just thought this meant someone could bypass the validations by making a request on something like Postman. But then I learned that with a same origin policy that's not possible. The same-origin policy is something that browsers voluntarily implement to protect their users. It ...


21

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


21

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


21

To put it simply: There is NO way As you already determined, a request can easily be forged. Even if using a custom encryption, your users can decompile your code and find out how it's done. The only way to prevent users from tampering and decompiling your code is by not handing it to them. Often this is done by providing SaaS products that run server ...


19

This could be a reasonable approach in certain circumstances: The customer gets read-only access. They get read access to an entire database: it's either quasi-public data to all your customers, or it contains only their own data. In particular it must not contain user PII or data that's otherwise subject to regulatory controls. You don't mind them reading ...


17

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


16

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


15

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


15

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


15

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


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


13

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


13

Here’s a Bayesian kind of answer... We collectively, as an industry, have about three decades experience designing 3-tier user-facing applications and have amassed a great body of knowledge on how to do it right. Deviating from this pattern isn’t necessarily wrong, as some of the other answers demonstrate, but you would be in sparsely travelled territory ...


13

Basically, you have to treat every input from the user as potentially malicious. Vidarlo has already mentioned two security issues and how they can be prevented in his answer. I'd also add that the content itself ("text:") could contain malicious code (e.g. javascript snippets). Make sure that this code is not executed on the receiving end. And I'd also ...


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