search

OWASP / ASVS

Application Security Verification Standard
Creative Commons Attribution Share Alike 4.0 International
2.74k stars 668 forks source link

v13: deserialization #526

Closed jaxley closed 5 years ago

jaxley commented 5 years ago

The current draft of 4.0 does not have any coverage of avoiding deserialization attacks like https://www.acunetix.com/blog/web-security-zone/deserialization-vulnerabilities-attacking-deserialization-in-js/ . I imagine OWASP has some pre-existing guidance that could be referenced here. e.g. don't use eval() and the like.

There are a number of remote code exec issues with deserialization that have plagued Java apps and the like that apply based on the library and configuration of the library used for deserializing. Most JSON parsers don't have these same issues as XML but some do.

elarlang commented 5 years ago

Have you read V5 category?

vanderaj commented 5 years ago

V5.5.1 - V5.5.4 covers this off. Are we missing any additional controls in there that you feel we need to cover? My preference is the broken design pattern of sending or receiving serialized objects to or from untrusted destinations is stopped. That belongs in V1.5, and I think we can clearly add that to the list of architectural controls.

vanderaj commented 5 years ago

I've included V1.5.2 to cover off the architectural anti-pattern. If we could stop folks sending objects, we would be a lot better off.

tghosth commented 5 years ago

I am going to close this as I think that between 1.5.2 and 5.5 it is addressed

jaxley commented 5 years ago

Again, apologies for not seeing the broader context. Glad to see it already covered!