Hi ,
I have delivered a workshop on this topic and would like to contribute in the testing guide by adding details on how to go about finding these issues in various languages like java,php,python,node..js and .NET
Please guide me as to how can i add the details
Hi Team, I am picking up the topic and working on it
Thank You
Vandana
Hey @vermava,
How far did you get with writing test scenario's for this one?
I can maybe give some assistance here since we also already have labs for insecure
deserialization.
https://owasp-skf.gitbook.io/asvs-write-ups/kbid-xxx-deserialisation-yaml
https://owasp-skf.gitbook.io/asvs-write-ups/kbid-xxx-des-pickle-2
@RiieCco I tried tagging Verma on another issue. No replies. You can move forward with this 馃槃
@RiieCco are you going to be able to tackle this?
For serialization issue, there are blackbox and whitebox approaches.
Refer to the section I have done for the CheatSheet. Let me know any section I can help to add?
Deserialization_Cheat_Sheet.html
Looking at the CS, that CS should belong in this project. It's purely offensive.
@rbsec @kingthorin what are your thoughts on this?
It ends with some offensive references but the majority of the article is about Deserializing Safely (from my skim of the content).
As for white vs blackbox. Although code review is mentioned in the TG it isn't really "testing", so blackbox is probably more applicable (ex: ways you'd identify and exploit during a penetration test or leveraging DAST).
The black/white box review stuff doesn't really belong, but there's a load of defensive stuff for Java and .NET.
It could certainly do with a cleanup, but I think it still has a place the in the cheat sheets project.
Lovely. This is something we can look at. (Rick it's not porting the whole CS)
Getting data from that CS for the WSTG, and refreshing the focus and look of the Deserialization CS.
Sounds good 馃憤
"How to test for Deserialisation of Untrusted Data" Is there any existing section or it will be a new section?
agree that the whitebox review can't verify the deserialization results, it can only narrow the scope
This needs to be added. I am getting vibes of adding this to Business Logic Testing, as it's on an object level and how processing is going to handle the object. If not, we downgrade to Input Val Testing
@kingthorin let me know what you think.
To me it's an Input Validation issue. Business Logic is more specific for things like improper handling of pricing, rebates, HR processes, orders, manufacturing, etc.
I agree with @kingthorin this is more regarding about Input Validation since it's the abuse of unexpected inputs to perform an action not desired or authorized. Commonly the impact would be a Business Logic exploitation but that's not a must condition. For example you can have an XML bomb that would be part of the deserialization of untrusted Data and results in a DoS instead of the manipulation of the Business Logic.
Mhm, agreed. I had a discussion back then with @kingthorin and we agreed on it being in Input Validation.
@Hsiang-Chih to answer you (apologies), this will have to be a new section.
Please comment if you are still working on this issue, as it has been inactive for 30 days. To give everyone a chance to contribute, we are releasing it to new contributors.
@vermava @RiieCco any news?
@kingthorin, i am on it again!