sasanlabs/vulnerableapp

OWASP VulnerableApp Project: For Security Enthusiasts by Security Enthusiasts.

vulnerableapp's Issues

Adding new Vulnerabilities to fulfill goal for handling 50 new vulnerabilities

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

Add data uri based xss attack

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

Attack vectors are missing in many levels because of CURL complexity

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

Adding support for Vulnerability SubType.

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.

In future this project might become heavy weight so we need to think on making it light weight.

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.

Adding this platform to break Encryptions/Weak Ciphers

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

Adding SpotLess to Project

1. Adding Spotless project dependency
2. Adding License Header
3. Both Maven and Gradle

thinking on handling of Post request based endpoints

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.

$Vulnerability_Missed$

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Additional context
Add any other context about the problem here.

Analysis on Adding Post Method support Seamlessly

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

1. Adding Method Type field in vulnerabilityRestEndpoint annotation but problem is scripting is something which doesn't want you to build a payload and then do the calls ie we need to build UI and doing a post call using UI.
2. Having a separate annotation and a separate flow for Post Calls which is not based on restEndPoint annotation.
3. Changing entire way to something else ie instead of using annotation approach using some kind of Command Pattern where each command correspond to one vulnerability and that command contains 2 methods vulnerable code and other is help.

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.

Path Traversal Vulnerability

Add Path traversal Vulnerability

Add More test cases for LFI

Integration with Owasp ZAP

Is your feature request related to a problem? Please describe.
#130 in this feature we have added all the required things/changes to Vulnerable App for Integration. Now we are tracking this integration using this Feature.
Need to followup with @psiinon for this feature.

Enhance VulnerableApp for adding Flag based levels like other VulnerableApplication have.

1. Introduce a new cookie and as per cookie run the entire application as Secure/insecure etc.
2. As endpoints are resolved by application so giving a way to go with Cookie based resolution and Url based resolution.
3. Only moving to Cookie based might not be good for someone who is testing url manually, trying to learn. (This is valid untill we are not converting app into Game.)
   eg is similar to DVWA where we choose levels and then we get the challenge .... for gamification of vulnerable app

Giving a way to create a vulnerability without annotation

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.

Add More tests for RFI

Design has race condition issue

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.

Adding Message labels to start with the vulnerability name

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.

Due to mongo insertion of data, many times server startup fails.

Fix the insertion of Data into Mongo. Server Startup fails and requires fix again and again.

Analysis on Making backend more robust.

Adding Design Docs.
Internal Review.

[Don't Pick]Adding CWE to the vulnerability types

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

Scanner Endpoint ❤️ vuln.json

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:

• Schema: https://github.com/OWASP/OWASP-VWAD/blob/6a8b54004db5b48278e82f2cc856fdc229c80ca3/src/owasp-wiki/deprecated/vulns-json/schema.json
• Example: https://github.com/OWASP/OWASP-VWAD/blob/6a8b54004db5b48278e82f2cc856fdc229c80ca3/src/owasp-wiki/deprecated/vulns-json/example/__vulns.json

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.

Adding annotation processor to restrict the return type of methods.

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.

Vulnerability descriptions are not proper

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.

JWT Vulnerabilities code reviews

1. Most of the code written is not scaling to multiple algorithms and it is written mostly for HS256 and RS256 but we need to make it scalable and easy to extend.
2. Code review is must as code is not as par with the standard for now and there can be array index out of bound or null pointers which need to be handled.
3. Reason for writing custom and using library is not mentioned, mention it so that we can remember the reasons.
   Reason for custom library is key length issues and JWK is difficult to provide as a custom so added JOSE library to handle that
4. Lots of refactoring can be done and it is pending so remove duplicate code.

Moving Build.gradle from deprecated compile to Implementation

Describe the bug
This is a techdebt task where we want to change build.gradle from compile to implementation

[Don't Pick ] Adding Support for extending and enhancing it with other TechStacks

Cannot pick it now as framework is not stable. But a Good Enhancement chunk for future.

Adding details to OWASP Website related to this project

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.

Adding UI for taking input from user in Text Box

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 logger to the Vulnerable App Project.

Logger setup is not done on VulnerableApp. Need to setup logger.
Log4j setup.

Adding checkstyle to vulnerable app

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.

Enabling Https and Secure cookie for JWT Vulnerability

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.

Lightweight tool

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

Case insensitive checks for URL encoding i.e. %2E is only checked in Path Traversal not %2e as both can work.

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.

Add more tests related to XSS

Add some Hook to help user to solve the problem.

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.

Design on making exploits easier until we are not building UI

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.

Adding Support for SQL injection

Describe the bug
Please add the support of SQL Injection too.

Adding Scoring system/Reporting system for Scanners

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.

All the vulnerabilities are having buffer overflow

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.

asdad

sdasda @preetkaran20

VulnerableApp.js makes call to the Vulnerablility Level URL before the click on level

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.

Analysis of Framework level UI changes.

Returning Ajax instead of HTML response from VulnerableRestEndPoint

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

Adding Login CSRF

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:

1. vulnerability related to Referrer header bypassing in case of Data uri and also incase of FTP uri.

Add Blind NoSQL injection to Mongo

Mongo DB adding blind sql injection where output is just true or false and finding APP Secret from HIddenEntity.

DOM based XSS

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

Eye Catcher Check is not there in Null Byte Injection attack causing ZAP to fail.

Adding Sample Values to JWT Vulnerability

JWT vulnerability is missing Sample Values. This is very important for ZAP integration. Need to fix this.
Related to #158

Add more tests for Command Injection