sasanlabs / vulnerableapp Goto Github PK
View Code? Open in Web Editor NEWOWASP VulnerableApp Project: For Security Enthusiasts by Security Enthusiasts.
Home Page: https://sasanlabs.github.io/VulnerableApp/
License: Apache License 2.0
OWASP VulnerableApp Project: For Security Enthusiasts by Security Enthusiasts.
Home Page: https://sasanlabs.github.io/VulnerableApp/
License: Apache License 2.0
JWT vulnerability is missing Sample Values. This is very important for ZAP integration. Need to fix this.
Related to #158
Cannot pick it now as framework is not stable. But a Good Enhancement chunk for future.
Till now Spring boot application is only available in Http but going further we want to enable Https,
incase we want to write some vulnerabilities related to poor SSL etc and Cookie based attacks in JWTVulnerabilities are not secure and hence we were not able to write a secured vulnerablity for JWT.
-> Enabling SSL
-> Http and Https both can exist
-> thinking more in how can a vulnerability choose between http and https or any other protocol
-> correcting JWTVulnerability to include secure attribute in cookie.
sdasda @preetkaran20
Describe the bug
As i am writing persistent XSS the practise vulnerability calls the VulnerableEndpoint even before the click of Practise vulnerability which is not a correct behavior. I understand that Level 1 should be invoked but we need to correct VulnerableApp.js to invoke the level1 url only Practise vulnerablity is clicked.
While going through vulnerability descriptions, found that they are not proper and needs a revisit.
Need to separate out where the value was found ie cookie or url or other place and the description of vulnerability.
Found while writing JWT Vulnerabilities
Also Description is the only parameter which is not right we should do the way ZAP is doing ie Desc plus Reference plus Solution plus more information as this makes it better.
Till now we are dependent on query params etc but user might not be familiar for what should be the parameter type or parameter key etc.
so until we are not giving UI we need to provide some way to tell user how they can execute exploit.
some standard ways can be creating one more endpoint like /allEndPoint where we can let user know the query param key etc things.
or something else.
we can also make documentation or description on /allEndpoint page better.
Hi! I really like your idea of having a kind of manifest of contained vulns in the application. There was actually an attempt to define a "standard" for this driven by https://github.com/OWASP/OWASP-VWAD in 2018 with @psiinon and others but it was dropped due to lack of interest/time/adoption rate/... at some point.
I dug up the artifacts of the __vulns.json
proposal from the repo:
The idea back then was, to have a very simple definition file that only maps some kind of flag
(could be a URL part or something else that would probably show up in a scanner's finding or report) with a type
of vulnerability where we defined a very limited list of things that scanners might be realistically able to find. At least I think that was the rationale...
Now with +2,5 years of experience with the https://github.com/bkimminich/juice-shop project, I would probably do some things a bit different, like rather specifying a known vuln identifier (OWASP-___ or CWE-_____ etc.) than an arbitrary key. Again, something that could easily be found in a scanner's report, so checking it's match rate would be relatively easy.
What I would stick to is having a file (JSON or YAML) in the repo rather than an endpoint to provide this information to the scanner. It can also be retrieved via HTTP-GET from GitHub but it would not spoiler all vulns too easily for human users of the vulnapp.
If you're interested in working out a shared specification, I would consider adding such a file to the Juice Shop as well. And maybe we could motivate others to do the same then.
Is your feature request related to a problem? Please describe.
Currently we have added XSS but that is only the usecase of Reflected XSS but there is no Persistent XSS or DOM based XSS. it would be better if we add that.
Describe the solution you'd like
As we have already integrated DB so we just need to create a Table and add UI for something like a Feedback form. Generic usecase of Persistent XSS. DOM based XSS need to be think more as it might require framework changes
Describe alternatives you've considered
Nothing
Describe the bug
This is a techdebt task where we want to change build.gradle from compile to implementation
Is your feature request related to a problem? Please describe.
For now all the vulnerable app endpoints are based on get request but certainly it might be tougher and going ahead we need to enable post based endpoints too.
This task is to analyse and think on handling post Request.
Describe the solution you'd like
Nothing in mind yet but need to think alot.
Describe alternatives you've considered
Nothing.
Additional context
Might not be very urgent but we are not sure when that becomes an absolute requirement.
As vulnerabilities are there with many technologies like SQL and NOSQL DB and various types.
So as the tech increases there can be chances of making tool very bulky so we need to seperate out PlatForm from Vulnerabilities and also we want to give a easy way to plugin in vulnerabilities related jars into the platform such that say user want to fix Mongo related vulnerabilities then we can plugin mongo into the platform.
With this we can also look into integrating multiple Languages related vulnerabilities into this tool.
Languages might be tough but it can be done.
Think Think Think
As message file is one and it is not per vulnerability so it is possible that message keys clash so we want vulnerabilityName to be prefix of the message key.
Or you can choose any other solution for this problem too like loading different message files for different vulnerabilityNames etc.
Vulnerability name is VulnerableRestEndPoint annotations value.
Going further in future this project might become very heavy weight so we need to think on making it in such a way that it will be light weight.
Describe the bug
As URL Encoding can work with any case hence we can either add 2-3 more levels in Path Traversal.
Path traversal assumes that case is always caps which is not right.
To Reproduce
Just change the case for the attackvector.
Need to handle both the cases else the vulnerability is incomplete.
Fix the insertion of Data into Mongo. Server Startup fails and requires fix again and again.
As we are writing the UI and we are solely relying on Ajax calls so we need to update the Endpoint handling which is currently returning HTML
As suggested by @bkimminich for including the CWE to the vulnerabilities for better collaboration across system so this Feature is to analyse the suggestion and implement it.
for more information: #164
thanks,
Karan
Mongo DB adding blind sql injection where output is just true or false and finding APP Secret from HIddenEntity.
Is your feature request related to a problem? Please describe.
Currently there is no way to mention small payload as attack vector and we can only add CURL request which is not easy to get when majority of developers are working with browsers so for now we can make Framework changes such that it can take simple payload.
Describe the solution you'd like
As Level already contains the information about the request which is useful for scanners we can also club both and build similar attack vector like:
url: <something>
requestlocation: COOKIE
parameterName: ipaddr
attackvector: 192.168.0.1 & pwd
we are always returning some page when ever attack is not successful. we need to add a way to return different pages like say help pages etc.
Till Today we can handle Get calls only and there is no way for Post calls handling. That is ok if we think of this application as only useful for scripting and injection attacks but going forward we might want to add something like CSRF or say Authentication vulnerabilities which requires post calls as a must.
Some solutions that i have in my mind are :-
but there are other things to it too. Like say SQL injection is a Parent/Umbrella vulnerability so it should be based on one UI and all the child vulnerability level code use the same UI to depict vulnerability.
requirement is to create a design wiki which handles the above stated problems.
Describe the bug
Please add the support of SQL Injection too.
Is your feature request related to a problem? Please describe.
Need to add more types of Vulnerabilities as this needs to be fulfilled before 31 july.
Describe the solution you'd like
Will start adding new vulnerabilities.
Describe alternatives you've considered
Nothing is an alternative. Sasan Hardwork is the Key.
Additional context
Reason for custom library is key length issues and JWK is difficult to provide as a custom so added JOSE library to handle that
Logger setup is not done on VulnerableApp. Need to setup logger.
Log4j setup.
Adding checkstyle to run in PR and also while building in local so that code is not having unused imports or other kind of code issues.
Is your feature request related to a problem? Please describe.
This platform looks great for writing new vulnerabilities and as i am learning new cryptographic algorithms so i would like to use this platform to test and break various algorithms so wanted to expose it as a platform for my usage
Describe the solution you'd like
If this projects works on exposing it like a library/platform which can easily plugged with other capabilities so that it can be used at various ends like testing different platforms like crypto libraries, NoSQL's etc it would be great.
Describe alternatives you've considered
adding crypto vulenrabilities to this platform only. However that will make this platform very bulky and using it as a platform in future might be tough
Additional context
Nothing as @preetkaran20(Sasan) Knows everything. !!! !!!
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
A clear and concise description of what you expected to happen.
Additional context
Add any other context about the problem here.
Our Annotation VulnerabilityLevel
should restrict the method to return a Bean whcich is same as response bean or extract an interface with all the methods and restrict on that interface so that error scenarios can be tamed.
Is your feature request related to a problem? Please describe.
Currently we have broad Vulnerability Types like SQL_INJECTION, XSS but we know these are further subdivided into multiple categories like ErrorBasedSQLInjection or UnionBasedSQLInjection or XSS_Reflected etc and if we can give a way to know the exact vulnerability type then it would be great for the Scanner or Students where they can exactly know about the Type and Subtype of vulnerability. It is always good to be granular.
Describe the solution you'd like
May be @VulnerabilityLevel annotation can be made on Subtypes and Subtypes will have Types which are umbrella Vulnerability type. This helps scanner too in the sense if scanner can report the bug but they should report subtype of bug.
Describe alternatives you've considered
This is important step in enabling reporting BI.
Is your feature request related to a problem? Please describe.
Adding Data uri based xss e.g. data:text/html,<script>alert('hi');</script>
Describe the solution you'd like
As XSS vulnerability is already there. it would be great if we add dataUri there too.
Describe alternatives you've considered
Nothing
Additional context
Waheguru !!! Satnaam
Is your feature request related to a problem? Please describe.
New vulnerability request is to add Login CSRF to this Project. It will be good for our project.
Describe the solution you'd like
Same as how we have XSS, we need to add Login CSRF
Describe alternatives you've considered
Nothing. New Feature Request.
Additional context
Also add following vulnerabilities:
Is your feature request related to a problem? Please describe.
As Scoring is one of the major task which is needed by the Vulnerable App for rating various scanners so we need a way to add/report the scores of Scanners.
Describe the solution you'd like
Say this tool is going well and now scanner like to rate themselves on how much percentage of vulnerabilities are covered by them then we need to give some kind of report.
Reporting is one of the task which can help this tool to work as a compliance matrix so we need to add such utility and i am thinking to add something very engineerish way not just count.
Describe alternatives you've considered
Nothing is the alternative
Additional context
thanks to @psiinon Project leader of @zaproxy for giving such valuable suggestion.
Is your feature request related to a problem? Please describe.
While working on creating UI for XSS i found that in case of XSS vulnerability there is no need to go to server and expose the endpoint.
can we have a way to expose the vulnerability without Annotation too then that can be helpful in writing UI related bugs.
Describe the solution you'd like
Creating some config file too for writing vulnerability
Describe alternatives you've considered
Alternative is to create dummy vulnerable endpoint which is not a big issue but it will be better from design prespective.
we want Vulnerabilities present in VulnerableApp are intended but each vuilnerable test is vulnerable to bufferoverflow so we want to fix this issue.
please add some kind of restriction on the return response bean.
URL restrict various unsafe character which might be ok for backend like {} etc which are used by mongo db injection. so this is urgent.
Adding Design Docs.
Internal Review.
Add Path traversal Vulnerability
As we are adding our project under Owasp so we are planning to add the details in OWASP website. Under this Jira we want to add the details similar to mentioned in Readme.md.
Describe the bug
Currently design is that we are passing ParameterBean as class instances hence it is causing multi threading issues which can be easily seen if we run ZAP fuzzer as answers are not correct everytime. This is observed in JWTVulnerability.
Expected behavior
Answers should always be certain from the Application and it should not have race condition issue.
Additional context
nothing.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.