How to prevent replay attack in REST API (Spring Boot based API)? [on hold]











up vote
-1
down vote

favorite
1












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:




  1. Generate the one time used unique challenge value and store in database with the status as "CREATED".


  2. Develop an API to get this challenge value.


  3. Client will send the request along with the challenge value.


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


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




  1. Each API will have to get the challenge value.


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







share|improve this 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















up vote
-1
down vote

favorite
1












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:




  1. Generate the one time used unique challenge value and store in database with the status as "CREATED".


  2. Develop an API to get this challenge value.


  3. Client will send the request along with the challenge value.


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


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




  1. Each API will have to get the challenge value.


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







share|improve this 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













up vote
-1
down vote

favorite
1









up vote
-1
down vote

favorite
1






1





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:




  1. Generate the one time used unique challenge value and store in database with the status as "CREATED".


  2. Develop an API to get this challenge value.


  3. Client will send the request along with the challenge value.


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


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




  1. Each API will have to get the challenge value.


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







share|improve this question















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:




  1. Generate the one time used unique challenge value and store in database with the status as "CREATED".


  2. Develop an API to get this challenge value.


  3. Client will send the request along with the challenge value.


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


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




  1. Each API will have to get the challenge value.


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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 19 hours ago









jonrsharpe

75.9k1098203




75.9k1098203










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


















  • 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

















active

oldest

votes






















active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes

-

Popular posts from this blog

Create new schema in PostgreSQL using DBeaver

Image
0 At the beginning of my current job I had limited access to DB but recently my role is changed to superuser, admin, and owner. My colleague who was the previous DB admin is able to create a schema or change the permissions as there is a permission tab in the properties and he can change permissions by clicking easily. Would you please let me know how I can create schema and change permissions as well? Why his dbeaver looks different from me? He can easily right click on the schema folder on top of all schemas on the left side column and select create new schema while I do not have that, like the following picture I found on the internet. postgresql database-schema dbeaver share | improve this question
Read more

Deepest pit of an array with Javascript: test on Codility

Image
0 $begingroup$ This is the question from a Codility test, as a task in an interview: DeepestPit - problem description A non-empty zero-indexed array A consisting of N integers is given. A pit in this array is any triplet of integers (P, Q, R) such that: ·         0 ≤ P < Q < R < N; ·         sequence [A[P], A[P+1], ..., A[Q]] is strictly decreasing, i.e. A[P] > A[P+1] > ... > A[Q]; ·         sequence A[Q], A[Q+1], ..., A[R] is strictly increasing, i.e. A[Q] < A[Q+1] < ... < A[R]. The depth of a pit (P, Q, R) is the number min {A[P] − A[Q], A[R] − A[Q]}. For example, consider array A consisting of 10 elements such that: A[0] = 0 A[1] = 1 A[2] = 3 A[3] = -2 A[4] = 0 A[5] = 1 A[6] = 0 A[7] = -3 A[8] = 2 A[9] = 3 Triplet (2, 3, 4) is
Read more

Costa Masnaga

Image
.mw-parser-output .avviso .mbox-text-div>div,.mw-parser-output .avviso .mbox-text-full-div>div{font-size:90%}.mw-parser-output .avviso .mbox-image div{width:52px}.mw-parser-output .avviso .mbox-text-full-div .hide-when-compact{display:block} Questa voce o sezione sull'argomento Lombardia non cita le fonti necessarie o quelle presenti sono insufficienti . Puoi migliorare questa voce aggiungendo citazioni da fonti attendibili secondo le linee guida sull'uso delle fonti. Segui i suggerimenti del progetto di riferimento. Costa Masnaga comune Localizzazione Stato   Italia Regione Lombardia Provincia Lecco Amministrazione Sindaco Sabina Panzeri (Al centro il cittadino) dall'08/06/2009 Territorio Coordinate 45°46′N 9°17′E  /  45.766667°N 9.283333°E 45.766667; 9.283333  ( Costa Masnaga ) Coordinate: 45°46′N 9°17′E  /  45.766667°N 9.283333°E 45.766667; 9.283333  ( Costa Masnaga ) Altitudine 318 m s.l.m
Read more