globocom / secdevlabs Goto Github PK

Currently we have only one app for this topic written in Python. It would be awesome having another application with a different language for this topic. Some suggestions are:

• Ruby
• Golang
• Java

You can check our Contributing Guidelines on creating a new app.
If you want to learn more about this topic, a very good reference would be OWASP's page.

Currently we have only one app for this topic written in PHP exploring a known vulnerability for an old version of Drupal. It would be awesome having another application with a different language for this topic, exploring another know vulnerability of any other software or lib.

Some suggestions of languages to write your app are:

• Ruby
• Golang
• Java

You can check our Contributing Guidelines on creating a new app.
If you want to learn more about this topic, a very good reference would be OWASP's page.

Currently we have only one app for this topic written in Golang. It would be awesome having another application with a different language for this topic. Some suggestions are:

• Ruby
• Python
• Java

You can check our Contributing Guidelines on creating a new app.
If you want to learn more about this topic, a very good reference would be OWASP's page.

This Hacktoberfest seems to be a good opportunity to update secDevLab's visual identity.

With that in mind, it would be awesome if we could update our logo to something different.

This tool is used in Amarelo Designs attack narrative and it would be great if we have instructions on how to install it on OSX.

Nowadays the app is can only be used through the terminal:

It would be great if we could add a web interface to the insecure-go-project such as these apps:

Following OWASP's mobile top 10 list, it would be awesome if we had an intentionally vulnerable M9-Reverse Engineering.

This app can be done in both iOS or Android environment, just be sure to add how one can deploy it and test it locally.

Just like the web applications, we also expect an attack narrative to demonstrate why this vulnerability is critical and should be fixed ASAP by its development team.

Currently we have only one app for this topic written in Python. It would be awesome having another application with a different language for this topic. Some suggestions are:

• Ruby
• Golang
• Java

You can check our Contributing Guidelines on creating a new app.
If you want to learn more about this topic, a very good reference would be OWASP's page.

Following OWASP's mobile top 10 list, it would be awesome if we had an intentionally vulnerable M4-Insecure Authentication.

This app can be done in both iOS or Android environment, just be sure to add how one can deploy it and test it locally.

Just like the web applications, we also expect an attack narrative to demonstrate why this vulnerability is critical and should be fixed ASAP by its development team.

The Pull Request template doesn't seem to be working properly by not showing up when a new one is created.

The PR template file can be found here:
PR Template

It would be nice if we have a guidance for people that are willing to contribute to SecDevLabs. Examples:

• Mitigation PR Template (How do I request a mitigation solution review from SecDevLabs community?)
• Attack Narrative PR Template (What if I have another attack narrative?)
• What labels must I use?
• I have just created an app! How can I send to SecDevLabs? (Building local environment guidance, etc..
• I have found an error! How do I report?

It will help filtering when others apps from each OWASP vulnerability are created.

The current directory organization is a little confusing. We have the folder owasp-top10-2017-apps that has only OWASP Top 10 2017 vulnerability list. What about OWASP API Security Top 10 2019 (or another lists)?
If we create a new folder for Top 10 2019 how would we handle with vulnerabilities that belongs to both lists?

The old IP 192.168.56.101 from VirtualBox .ova is being shown. As we are now using docker-compose, it is better to use new evidencies using localhost as address.

As we now have a FE, (thanks @mdjunior !) we could change our banner image.

We currently only have one app for A1 (Injection) topic containing an SQL Injection vulnerability. Since Injection is a big topic, it would be awesome if we had another application approaching a different type of Injection, like:

• Command Injection
• Server-side Template Injection
• NOSQL Injection

and many more!

This new app could also be written in a different language than the current one (Golang). Some suggestions are:

• Ruby
• Python
• Java

You can check our Contributing Guidelines on creating a new app.

Also it would be nice if fix the section after "Deploy and Run" such as this commit.

Is your feature request related to a problem? Please describe.
Sometimes it's difficult for the secDevLabs community to identify which app a solution is proposed to and what was done.

Describe the solution you'd like
Create a template for the solutions with:

• This solution refers to which of the apps?
• What did you do to mitigate the vulnerability?
• Did you test your changes? What commands did you run?

It would be nice if we add a simple note on ATTACK.md files where brew install exploitdb is being used.

Update README_Template.md file to use the new README template.

Following OWASP's mobile top 10 list, it would be awesome if we had a intentionally vulnerable M2-Insecure Data Storage.

This app can be done in both iOS or Android environment, just be sure to add how one can deploy it and test it locally.

Just like the web applications, we also expect an attack narrative to demonstrate why this vulnerability is critical and should be fixed ASAP by its development team.

The text shown in Cimentech's home page is the drupal's default, we should change that to better fit the app's theme.

Following OWASP's mobile top 10 list, it would be awesome if we had an intentionally vulnerable M5-Insufficient Cryptography.

This app can be done in both iOS or Android environment, just be sure to add how one can deploy it and test it locally.

Just like the web applications, we also expect an attack narrative to demonstrate why this vulnerability is critical and should be fixed ASAP by its development team.

The way the project is today when we execute make install, the containers relative to the app are built and a script validates if the app started successfully. If it did, this message should appear:

The problem lies when, after coding the desired changes to mitigate a vulnerability, the container fails to start due to a mistake and the check lasts for a very long time, as shown by the image below:

It would be great if we could tell the developer early that something went wrong. This way, there's no need to wait for the timeout.

Some developers may not have installed it already in their machines.

Following OWASP's mobile top 10 list, it would be awesome if we had an intentionally vulnerable M6-Insecure Authorization.

This app can be done in both iOS or Android environment, just be sure to add how one can deploy it and test it locally.

Just like the web applications, we also expect an attack narrative to demonstrate why this vulnerability is critical and should be fixed ASAP by its development team.

The way Vulnerable Wordpress Misconfig is today, we are using this default look:

It would be great if the app could have its own identity, just like all the other apps. Maybe changing the website to some kind of blog, company's page or some other cool idea!

It would be a good idea to describe how to set up the burp and how to send it to Intruder.

Following OWASP's mobile top 10 list, it would be awesome if we had an intentionally vulnerable M10-Extraneous Functionality.

This app can be done in both iOS or Android environment, just be sure to add how one can deploy it and test it locally.

Just like the web applications, we also expect an attack narrative to demonstrate why this vulnerability is critical and should be fixed ASAP by its development team.

After reviewing some documentation ([1] and [2]), Insecure Go Project looks more like an A2 app, not A3.

[1] https://cwe.mitre.org/data/definitions/798.html
[2] https://www.templarbit.com/blog/2018/02/08/owasp-top-10-vs-sans-cwe-25/

Through some of the apps, such as CopyNPaste API, Vulnerable Wordpress Misconfig, Stegonography and Amarelo Designs, the following tools are used to perform automated tasks: SQLMap, WPScan and Dirb.

Sometimes it can be a hassle for people to properly install these tools, some can be quite challenging to install on Mac OS. With that in mind, it would be great if we could build a container with all these security tools already installed and ready to go. Having that, all a developer would need to do is run the container and use the tools on the intentionally vulnerable apps of secDevLabs.

Some links are with the string [this section], others [this]. It would be nice do this little fix. 😎

Currently we have only one app for this topic written in Python. It would be awesome having another application with a different language for this topic. Some suggestions are:

• Ruby
• Golang
• Java

You can check our Contributing Guidelines on creating a new app.
If you want to learn more about this topic, a very good reference would be OWASP's page.

When accessing localhost:10033, it would be great if we redirect to /login.

When we sign up, Ecommerce API does not validate if our username exists in database.

Following OWASP's mobile top 10 list, it would be awesome if we had an intentionally vulnerable M8-Code Tampering.

This app can be done in both iOS or Android environment, just be sure to add how one can deploy it and test it locally.

Just like the web applications, we also expect an attack narrative to demonstrate why this vulnerability is critical and should be fixed ASAP by its development team.

Currently we have only one app for this topic written in PHP. It would be awesome having another application with a different language for this topic. Some suggestions are:

• C/C++
• Java
• .NET

You can check our Contributing Guidelines on creating a new app.
If you want to learn more about this topic and maybe grab some ideas on how to make a vulnerable app, check out OWASP's page.

I'm trying to exploit the SQLi remotely but when I perform the dump after successfully exploit the vulnerability, it returns me no entries in the 'Users' table. But if I exploit it locally, it returns me the entries properly.
I also noticed that I'm not able to register an user in a remote access via web browser, when I call the registration page, I got:

• "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:3000/register. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing)."
  Are there any configs that I have to change to get to use the LAB remotely?

Motivation

Copy-and-Paste's attack narrative makes use only of SQLMap to show how an automated SQL injection could be performed.

It would be great if

We could also have the queries needed to perform an exploration of the intentionally vulnerable app manually. This would be interesting due to the fact that SQLMap can be very intrusive and dangerous to the application functionality.

What we expect

We expect to have the manual steps written down in the README.md with an explanation on how and why these commands work.

curl -s -H "Content-Type: application/json" -d '{"user":"-1'\'' <sqli payload here> ", "pass":"password"}' http://127.0.0.1:10001/login

Tips

• Testing for SQL Injection - OWASP
• Full SQL Injection Tutorial - Exploit DB
• SQL Injection Ninja Testing Labs - LeetTime

After building the app, it is not possible to follow the attack narrative and reproduce the exploitation.

Maybe docker running in Linux has some different protections.

Issue found by @mbenford . Thanks for that! 👏🏻

Following OWASP's mobile top 10 list, it would be awesome if we had an intentionally vulnerable M7-Poor Code Quality.

This app can be done in both iOS or Android environment, just be sure to add how one can deploy it and test it locally.

Just like the web applications, we also expect an attack narrative to demonstrate why this vulnerability is critical and should be fixed ASAP by its development team.

Following OWASP's mobile top 10 list, it would be awesome if we had an intentionally vulnerable M1 - Improper Platform Usage app.

This app can be done in both iOS or Android environment, just be sure to add how one can deploy it and test it locally.

Just like the web applications, we also expect an attack narrative to demonstrate why this vulnerability is critical and should be fixed ASAP by its development team.

Following OWASP's mobile top 10 list, it would be awesome if we had a intentionally vulnerable M3-Insecure Communication.

This app can be done in both iOS or Android environment, just be sure to add how one can deploy it and test it locally.

Just like the web applications, we also expect an attack narrative to demonstrate why this vulnerability is critical and should be fixed ASAP by its development team.

In most of our apps, the ports were chosen randomly, which might leave people lost as to which port to access to get to the action.

In order to standardize all of our apps, it would be great if we could change the ports to this pattern:

• A1 App - Port : 10001
• A2 App - Port: 10002
• A3 App - Port: 10003
• A4 App - Port: 10004
• A5 App - Port: 10005
• A6 App - Port: 10006
• A7 App - Port: 10007
• A8 App - Port: 10008
• A9 App - Port: 10009
• A10 App - Port: 10010

After building CopyNPaste app and sending a login or register request through the web interface buttons, a 405 Method Not Allowed message is returned.

This seems to happen only on the application's web interface. If we use curl the application works as intended as shown below.

Request:

curl -s -H "Content-Type: application/json" -d '{"user":"test", "pass":"test"}' http://127.0.0.1:3000/login

Response:

User not found or wrong password!

Smartphones are everywhere nowadays and there are thousands of developers dedicated to creating new apps for them every day. With that in mind, it would be awesome with could help them by providing intentionally vulnerable mobile applications, so they could get to know better the most common vulnerabilities and how to fix them.

With that in mind, we could use OWASP's mobile top 10 list as a guide.
The topics featured in the list are:

• M1-Improper Platform Usage
• M2-Insecure Data Storage
• M3-Insecure Communication
• M4-Insecure Authentication
• M5-Insufficient Cryptography
• M6-Insecure Authorization
• M7-Poor Code Quality
• M8-Code Tampering
• M9-Reverse Engineering
• M10-Extraneous Functionality

The new apps' path should be something along the lines of: secDevLabs/owasp-top10-2016-mobile.