Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disallow request in the future. #119

Merged
merged 1 commit into from
Oct 28, 2016
Merged

Conversation

fwininger
Copy link
Collaborator

Currently we disallow requests on the past to block replay attack, but a request in the future is always valid. It seems to be good to have the same behaviour.

@kjg
Copy link
Collaborator

kjg commented Jul 19, 2016

Why would an otherwise valid request in the future be a security risk? A request that is too old might be a reply of an already made request. But if the request is in the future and the signature is valid, what's the concern other than just a longer window in which a reply of a request would still have a valid signature?

@fwininger
Copy link
Collaborator Author

Sorry for the deplay, I was very busy last week.

To prevent replay attack by timestamping, is very important to have a limited windows. Usualy less than 1 second. It's Ok to have +/- 15 minutes, but in our case, if the server is one day late or the client is one day earlier, ApiAuth allows a windows of 1 day for the replay attack.

Some references :

https://en.wikipedia.org/wiki/Replay_attack

Timestamping is another way of preventing a replay attack. Synchronization should be achieved using a secure protocol. For example Bob periodically broadcasts the time on his clock together with a MAC. When Alice wants to send Bob a message, she includes her best estimate of the time on his clock in her message, which is also authenticated. Bob only accepts messages for which the timestamp is within a reasonable tolerance. The advantage of this scheme is that Bob does not need to generate (pseudo-) random numbers, with the trade-off being that replay attacks, if they are performed quickly enough i.e. within that 'reasonable' limit, could succeed.

https://docs.wso2.com/display/IS500/Timestamp+in+WS-Security+to+Mitigate+Replay+Attacks

@kjg
Copy link
Collaborator

kjg commented Oct 26, 2016

After some discussion on other issues, I realize that allowing requests in the distant future also allows for a bad actor trying to "guess" the signature for their own crafted request more time to guess it if they set their own request date header super far in the future.

@kjg kjg merged commit bc62410 into mgomes:master Oct 28, 2016
kjg added a commit that referenced this pull request Oct 28, 2016
Disallow request in the future.
@fwininger
Copy link
Collaborator Author

Thanks 👍

@fwininger fwininger deleted the security_fix branch November 2, 2016 07:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants