How to prevent replay attack in REST API (Spring Boot based API)? [on hold]
up vote
-1
down vote
favorite
As part of security scanning, security team identified the API which we developed "attacker can do a replay the API (Replay attack)"
Technical approach that I am proposing:
Generate the one time used unique challenge value and store in database with the status as "CREATED".
Develop an API to get this challenge value.
Client will send the request along with the challenge value.
Backend server will validate the challenge value (Checks the values in database and status as "CREATED") and end of the request processing change the status as "USED".
If the same request will be replayed the status of the challenge value is USED hence we will consider as this request is replayed.
Disadvantages:
Each API will have to get the challenge value.
Increasing of the database table size .
I am not sure this approach is the best one. Looking for some more best approaches to avoid the reply attack for REST API.
- Backend: Spring Boot.
- Front end: iOS and Android based app.
spring spring-boot spring-security owasp
edited 19 hours ago
jonrsharpe
75.9k1098203
asked 20 hours ago
Maddy
99111
put on hold as too broad by dur, sideshowbarker, Gabor Lengyel, jww, Vega 10 hours ago
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
up vote
-1
down vote
favorite
As part of security scanning, security team identified the API which we developed "attacker can do a replay the API (Replay attack)"
Technical approach that I am proposing:
Generate the one time used unique challenge value and store in database with the status as "CREATED".
Develop an API to get this challenge value.
Client will send the request along with the challenge value.
Backend server will validate the challenge value (Checks the values in database and status as "CREATED") and end of the request processing change the status as "USED".
If the same request will be replayed the status of the challenge value is USED hence we will consider as this request is replayed.
Disadvantages:
Each API will have to get the challenge value.
Increasing of the database table size .
I am not sure this approach is the best one. Looking for some more best approaches to avoid the reply attack for REST API.
- Backend: Spring Boot.
- Front end: iOS and Android based app.
spring spring-boot spring-security owasp
edited 19 hours ago
jonrsharpe
75.9k1098203
asked 20 hours ago
Maddy
99111
put on hold as too broad by dur, sideshowbarker, Gabor Lengyel, jww, Vega 10 hours ago
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
It's not clear from the question what the vulnerability was (what exactly they could replay and what they could achieve). Therefore it's not possible to advise on mitigation. In general, replay attacks are associated with state stored on the client. First you need to get a better understanding of what the actual problem is, because I suspect the solution you proposed is a solution to something else. :)
– Gabor Lengyel
12 hours ago
add a comment |
up vote
-1
down vote
favorite
up vote
-1
down vote
favorite
As part of security scanning, security team identified the API which we developed "attacker can do a replay the API (Replay attack)"
Technical approach that I am proposing:
Generate the one time used unique challenge value and store in database with the status as "CREATED".
Develop an API to get this challenge value.
Client will send the request along with the challenge value.
Backend server will validate the challenge value (Checks the values in database and status as "CREATED") and end of the request processing change the status as "USED".
If the same request will be replayed the status of the challenge value is USED hence we will consider as this request is replayed.
Disadvantages:
Each API will have to get the challenge value.
Increasing of the database table size .
I am not sure this approach is the best one. Looking for some more best approaches to avoid the reply attack for REST API.
- Backend: Spring Boot.
- Front end: iOS and Android based app.
spring spring-boot spring-security owasp
edited 19 hours ago
jonrsharpe
75.9k1098203
asked 20 hours ago
Maddy
99111
As part of security scanning, security team identified the API which we developed "attacker can do a replay the API (Replay attack)"
Technical approach that I am proposing:
Generate the one time used unique challenge value and store in database with the status as "CREATED".
Develop an API to get this challenge value.
Client will send the request along with the challenge value.
Backend server will validate the challenge value (Checks the values in database and status as "CREATED") and end of the request processing change the status as "USED".
If the same request will be replayed the status of the challenge value is USED hence we will consider as this request is replayed.
Disadvantages:
Each API will have to get the challenge value.
Increasing of the database table size .
I am not sure this approach is the best one. Looking for some more best approaches to avoid the reply attack for REST API.
- Backend: Spring Boot.
- Front end: iOS and Android based app.
spring spring-boot spring-security owasp
spring spring-boot spring-security owasp
edited 19 hours ago
jonrsharpe
75.9k1098203
asked 20 hours ago
Maddy
99111
edited 19 hours ago
jonrsharpe
75.9k1098203
asked 20 hours ago
Maddy
99111
edited 19 hours ago
jonrsharpe
75.9k1098203
edited 19 hours ago
jonrsharpe
75.9k1098203
edited 19 hours ago
jonrsharpe
75.9k1098203
75.9k1098203
asked 20 hours ago
Maddy
99111
asked 20 hours ago
Maddy
99111
asked 20 hours ago
Maddy
99111
99111
put on hold as too broad by dur, sideshowbarker, Gabor Lengyel, jww, Vega 10 hours ago
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
put on hold as too broad by dur, sideshowbarker, Gabor Lengyel, jww, Vega 10 hours ago
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
It's not clear from the question what the vulnerability was (what exactly they could replay and what they could achieve). Therefore it's not possible to advise on mitigation. In general, replay attacks are associated with state stored on the client. First you need to get a better understanding of what the actual problem is, because I suspect the solution you proposed is a solution to something else. :)
– Gabor Lengyel
12 hours ago
add a comment |
It's not clear from the question what the vulnerability was (what exactly they could replay and what they could achieve). Therefore it's not possible to advise on mitigation. In general, replay attacks are associated with state stored on the client. First you need to get a better understanding of what the actual problem is, because I suspect the solution you proposed is a solution to something else. :)
– Gabor Lengyel
12 hours ago
It's not clear from the question what the vulnerability was (what exactly they could replay and what they could achieve). Therefore it's not possible to advise on mitigation. In general, replay attacks are associated with state stored on the client. First you need to get a better understanding of what the actual problem is, because I suspect the solution you proposed is a solution to something else. :)
– Gabor Lengyel
12 hours ago
It's not clear from the question what the vulnerability was (what exactly they could replay and what they could achieve). Therefore it's not possible to advise on mitigation. In general, replay attacks are associated with state stored on the client. First you need to get a better understanding of what the actual problem is, because I suspect the solution you proposed is a solution to something else. :)
– Gabor Lengyel
12 hours ago
add a comment |
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
It's not clear from the question what the vulnerability was (what exactly they could replay and what they could achieve). Therefore it's not possible to advise on mitigation. In general, replay attacks are associated with state stored on the client. First you need to get a better understanding of what the actual problem is, because I suspect the solution you proposed is a solution to something else. :)
– Gabor Lengyel
12 hours ago