The example provided isn't really an example of insecure deserialization. If the application is relying on a cookie to determine the user's role within the application that would be broken access control. A more realistic example would be something like: - The application expects the cookie to contain a serialized UserState object with things like the user's preferences. Pseudo code something like: {o:UserState:{a:viewPreferences:{view:list,numberPerPage:30,sort:Price}}} - The application unserializes the cookie and calls some methods on the UserState object - Instead of a serialized UserState object, the attacker sends a serialized object of an unexpected type: e.g. {o:DatabaseConnection:{a:properties:{query: DROP DATABASE foo;}}} - The application unserializes the unexpected object type and calls methods on it leading to unexpected code execution. Also note there are automated ways to check this. For example, you could run the value of all the Cookies set against you against a RegEx to see if they look like serialized objects.
Hi Max...thanks for the comment and the additional data. Just for clarification, I was using the "super cookie" example (Attack Scenario #2) that OWASP uses in their literature here: www.owasp.org/index.php/Top_10-2017_A8-Insecure_Deserialization In this example, a PHP forum uses PHP object serialization to save a "super" cookie, containing the user's user ID, role, password hash, and other state... An attacker changes the serialized object to give themselves admin privileges...
@@devcentral After I wrote this comment I looked at the OWASP doc and saw the content was based off that. It seems like OWASP themselves actually don't fully understand the vulnerability. twitter.com/maxpchadwick/status/1092818227829317639?s=20
@@MaxChadwick thanks for the reply and the clarification. I'll certainly look into this. Appreciate the ongoing discussion and clarification...the end goal is to explain the issue of this security risk, so we need to make sure that is done clearly and effectively (and accurately!!). Thanks again!
Nice Video...Thanks for it Can you make a video on different types of Insecure Deserialization with examples: i.e, Blind Deserialization Asynchronous Deserialization Deferred Execution Deserialization
The bit about the classification of the vulnerability sort: if, say, cookie content is used to recreate a server side object in, e.g, Java or .NET, then that's the risk for insecure deserialization.
Thanks for sharing! I want to explain the mechanism a tiny bit more; ie. one way would be if the attacker changes the serialised user name to "Alice:Admin:123:xyz --#" then when that's deserialised the bits of her name get split on the colons and populate the other fields. Everything after the # is a comment and ignored. it grants full access tho is tricky to put into practice. Thanks again :)
Did nobody else notice and wonder about how he made the video? We are seeing content from left to write and that is only possible if he is writing from right to left because the camera appears to be in front of him?
Thanks for the comment Swapnil...Just for clarification, I was using the "super cookie" example (Attack Scenario #2) that OWASP uses in their literature here: www.owasp.org/index.php/Top_10-2017_A8-Insecure_Deserialization In this example, a PHP forum uses PHP object serialization to save a "super" cookie, containing the user's user ID, role, password hash, and other state... An attacker changes the serialized object to give themselves admin privileges... Other people have commented on this as well...I'll make sure we use a better (more clear) example next time around. Thanks again!
Hi, Great videos, I have a question do you guys know of or are making a video on how to perform a pen test based on OWASP Top 10? That would be awesome.
It's hard to say because it's difficult to automatically scan for them. The OWASP organization says that this risk was added because of the feedback it got during the "TopTen" survey they did for the 2017 list. But, they also say that, with improved toolsets to find this risk in the future, the risk might make it higher on the list next time around.
The example provided isn't really an example of insecure deserialization. If the application is relying on a cookie to determine the user's role within the application that would be broken access control.
A more realistic example would be something like:
- The application expects the cookie to contain a serialized UserState object with things like the user's preferences. Pseudo code something like: {o:UserState:{a:viewPreferences:{view:list,numberPerPage:30,sort:Price}}}
- The application unserializes the cookie and calls some methods on the UserState object
- Instead of a serialized UserState object, the attacker sends a serialized object of an unexpected type: e.g. {o:DatabaseConnection:{a:properties:{query: DROP DATABASE foo;}}}
- The application unserializes the unexpected object type and calls methods on it leading to unexpected code execution.
Also note there are automated ways to check this. For example, you could run the value of all the Cookies set against you against a RegEx to see if they look like serialized objects.
Hi Max...thanks for the comment and the additional data. Just for clarification, I was using the "super cookie" example (Attack Scenario #2) that OWASP uses in their literature here: www.owasp.org/index.php/Top_10-2017_A8-Insecure_Deserialization
In this example, a PHP forum uses PHP object serialization to save a "super" cookie, containing the user's user ID, role, password hash, and other state... An attacker changes the serialized object to give themselves admin privileges...
@@devcentral After I wrote this comment I looked at the OWASP doc and saw the content was based off that. It seems like OWASP themselves actually don't fully understand the vulnerability. twitter.com/maxpchadwick/status/1092818227829317639?s=20
@@MaxChadwick thanks for the reply and the clarification. I'll certainly look into this. Appreciate the ongoing discussion and clarification...the end goal is to explain the issue of this security risk, so we need to make sure that is done clearly and effectively (and accurately!!). Thanks again!
Thanks for this deeper explanation. This makes more sense. The largest threat here is unauthorized code execution, which is very serious indeed.
Nice Video...Thanks for it
Can you make a video on different types of Insecure Deserialization with examples: i.e,
Blind Deserialization
Asynchronous Deserialization
Deferred Execution Deserialization
The bit about the classification of the vulnerability sort: if, say, cookie content is used to recreate a server side object in, e.g, Java or .NET, then that's the risk for insecure deserialization.
Thanks for the additional info...great stuff!
Beautifully explained, thank you!
glad you enjoyed it!
Great video, TY!
Thanks for sharing! I want to explain the mechanism a tiny bit more; ie. one way would be if the attacker changes the serialised user name to "Alice:Admin:123:xyz --#" then when that's deserialised the bits of her name get split on the colons and populate the other fields. Everything after the # is a comment and ignored. it grants full access tho is tricky to put into practice. Thanks again :)
thanks for the added info!
Awesome series !!!
glad you enjoy the videos!
Did nobody else notice and wonder about how he made the video? We are seeing content from left to write and that is only possible if he is writing from right to left because the camera appears to be in front of him?
Excelent video and explanation
glad you enjoyed it!
I hate to ask, but in what universe would you rely on input from the user to determine their role?
This example looks more like an example of IDOR (Insecure Direct Object Reference) than of Insecure Deserialization.
Thanks for the comment Swapnil...Just for clarification, I was using the "super cookie" example (Attack Scenario #2) that OWASP uses in their literature here: www.owasp.org/index.php/Top_10-2017_A8-Insecure_Deserialization
In this example, a PHP forum uses PHP object serialization to save a "super" cookie, containing the user's user ID, role, password hash, and other state... An attacker changes the serialized object to give themselves admin privileges...
Other people have commented on this as well...I'll make sure we use a better (more clear) example next time around. Thanks again!
Really awesome video, I do have a question, if an attacker is able to change prices, is it regarded as objects deserlisation
Thanks.
Nice series, it helped me understand the top 10s especially Insecure Deserialization. Thanks.
glad you enjoyed it!
thanks for sharing dude i just subscribed
awesome...thanks!
Thanks
Hi, Great videos, I have a question do you guys know of or are making a video on how to perform a pen test based on OWASP Top 10? That would be awesome.
thx for this video! - i'm wondering how you managed that mirror-writing...
Here's an explanation of how it all works: devcentral.f5.com/s/articles/lightboard-lessons-behind-the-scenes
Awesome Series! thanks for all the information !
glad you enjoyed it!
Great overview! Thanks for posting!
glad you enjoyed it!
How is he writing backwards?
Thanks for the note and this is how we produce these: ua-cam.com/video/U7E_L4wCPTc/v-deo.html
nice serial ;)
How common are insecure deserialization issues?
It's hard to say because it's difficult to automatically scan for them. The OWASP organization says that this risk was added because of the feedback it got during the "TopTen" survey they did for the 2017 list. But, they also say that, with improved toolsets to find this risk in the future, the risk might make it higher on the list next time around.
dont be insecure
table.tex().reverse();
1234