Xander

Could be!

Happy birthday Security Stack Exchange! Today is a major milestone.... sec.SE officially becomes a teenager.

^- This.

@MechMK1 Ah, yeah. that would be a problem.

@MechMK1 Decompile and recompile? Tools like Reflector and dotPeek have the ability to export assemblies to projects. That's probably the easiest way. Depending on what changes you're making, there's also ILDAMS/ILASM if you don't mind working directly with MSIL. I'm not aware of a way to persistently edit the assembly directly.

Oh, and also it was a setup by the industry, who is threatened by the fact that they're going to replace with RSA, which they still seem to inexplicably believe is the only cryptographic algorithm currently in existence.

@forest I read the lawsuit. It's pretty hilarious. Much as the article you quoted suggests, basically it boils down to that they feel they didn't get their money's worth because people were mean to them and hurt their feelings. They just repeat about 20 different variations on that theme.

@forest It's generally true. Of course there will always be weird edge cases.

Later!

@Ghawblin No worries! That's why we have the ability to vote to move it around. :-)

@JourneymanGeek Done.

@MechMK1 Yeah, I'd agree that it's a better fit at SU. @JourneymanGeek what say you?

@MechMK1 Yes certainly, that is true performance aside. But even for unsalted hashes it isn't a particularly efficient approach any longer.

So, while that was certainly originally true and the theory still holds, in practice modern computers have dumped the theory on its head.

For the last decade or so the cost of hash computation has been generally low enough that it's cheaper than storing and looking up the hashes.

As an aside, this "By using pre-computation, you (or someone else) perform the "heavy lifting" beforehand. Comparing a found hash with an already existing one is very quick and only requires "looking it up" in the existing hash database." is pretty archaic. Computational power is so cheaply and readily available these days that that rainbow tables are not really a thing any more.

@MechMK1 You are not wrong.

Plus they save you a lot of nonsense findings in SAST reports. :-D

Yup

@RoryAlsop Fun! Will have to look around.

@RoryAlsop Interesting! Kristin's mused about us doing an online wine tasting. We haven't yet, but might try it out.

@RoryAlsop Have you been doing them?

The lack of a querystring parameter on the GET request is neither a vulnerability in and of itself, nor would it be a mitigation if there is a vulnerability in the system.

@MartinFürholz Yes, I'm very much following. The problem is that the system you've described is generically, an application that interacts with an API. It creates/updates data with POST and PUT requests, and retrieves data with GET requests. This is how all APIs work. You've then speculated that there might be a security concern, but provided no additional data to lead us to believe that there is any more reason for that to exist here than in any other RESTful API.

@MartinFürholz Look, the only reasons I visit this site are to learn, and to help other people. I have no vested interest in being right, or proving you wrong. I'm only trying to help you understand what I see about the system you've described. If you don't find my input helpful, then just let me know and I'll bow out.

Yes, it is possible to imagine examples of ways there may be security issues. That is true of any system. The trick is figuring out whether or not any of them actually exist, and there's nothing in your description of the system that indicates they do, and we can't know any more than that without testing the system, but the architecture itself is not a concern.

@MartinFürholz I'm sorry, I don't know how to say it any more plainly. There are no general security concerns for the system you described. That doesn't mean that there are no security concerns present, just that nothing you described is in and of itself alarming.

@MartinFürholz "But "be nice" also includes answering, and not ignoring, my questions."

@MartinFürholz So, you don't want a answer, you want confirmation of the position that you've already formed.

@MartinFürholz You did get answers. In a round-about way, the answers all said the same thing which more succinctly is that generally "No, it isn't a bad practice and no, there generally aren't security implications."

I responded in chat

I agree with @RoryAlsop. The edits don't change that the question is premised on a misunderstanding how HTTP and this application work. Without that misunderstanding, there is no question.

"what you are saying is that GET url.com/image001.jpg is NOT supposed to return image001.jpg everytime you call it, but it's perfectly fine if it sometimes returns image999.jpg's representation, or image444.jpg's representation." I can't see the image, but what I'm saying is there's nothing in your post to indicate that it doesn't.

And specifically, this "It's not idempotent, because it gives a different result, if the user sent the first POST request with different data inbetween." is where you go wrong. The POST is separate request, and has nothing to do with the GET, and if they're using something in the session to determine what comes back in the GET (which it appears they are) that's perfectly fine.

There are many ways to make a request distinct and unambiguous. A URL parameter is only one of them. And along with everyone else, I have to point out that you misunderstand the meaning of "idempotent" which renders the question baseless.

Yes, I'm fully aware of the RFC 2616 definition, and that's not the problem. The problem is that you're trying to apply it to something that does not meet that definition, so your question doesn't make any sense.

You have to be able to define the threat that is at issue. That the user sees different data than what they submitted is not a threat. If there is a specific risk associated with the user seeing different data than what was submitted, then that is the potential threat, and you have to be able to describe how the current architecture allows that threat to be turned into a vulnerability, and how your proposed change eliminates that vulnerability.

@MartinFürholz Ultimately, if you can demonstrate that the data that is POSTed is mutable and there's a reasonable path for an attacker to manipulate it between significant legitimate user interactions, that would something worth looking into. But from a security perspective, whether the data is returned as a POST response or a subsequent GET response, and whether the identifier is a querystring parameter or a session id are both irrelevant in general terms.

@MartinFürholz 'And since I explained that there is 'literally nothing else' in the request, that means that would be prone to CSRF.' If that's true for the POST as well as the GET then yes, that's true, which wouldn't be uncommon for an API.

Rooted devices are generally always going to be outside of any threat model. An attacker who can modify an application on a rooted device is effectively the user.

@MartinFürholz And is there a CSRF?

@MartinFürholz Is the data mutable?

@MartinFürholz fact, your proposal could indeed make it worse. If the resource is mutable and a CSRF can be taken advantage of in that period, then the attacker would execute it, changing the data in the database, but the response for the POST would show the data that the user expects to see (the data they submitted) rather than the current data (the data the attacker submitted milliseconds later.)

@MartinFürholz I was responding to your statement that it was "not clear" to you.

@MartinFürholz If the resource is mutable, and there is a CSRF, it could be changed at any time the CSRF is available to be taken advantage of by the attacker. Generally, the milliseconds between when the user submits some data and when the user reviews that data is going to be the least likely point an attacker would want to take advantage.

@MartinFürholz It does though, by sending the cookie with the session id. I predict that if you send that exactly GET request that you described over and over, (the method, the API endpoint, and the session cookie) you're going to get the same data back every time.

Does that make it any clearer?

That, effectively seems to be what's happening with the application that you're looking at.

Then when you issue a GET request for the /account-home/ with that session cookie, it'll check the user in the session associated with the session id, and the response will be a page with the accounts and balances associated with that user. If you re-issue that same GET 500 more times, you'll always get the accounts and balances associated with that session/authenticated user.

@MartinFürholz Perhaps this example might be helpful. Think of an online banking website. The first page you'll visit is a login page. You'll POST your credentials, and once the server has validated them, it'll put your authenticated user information in session state, and return a session cookie with your session id.