This document discusses security issues related to broken access control and security misconfiguration. It provides examples of broken access control including modifying URL parameters to access restricted resources, restricting folder access, and using malicious URLs as parameters. Recommendations are given to implement access controls consistently, limit account data changes to account holders, and log access control failures. Examples of security misconfiguration include using default credentials and configurations, having an overly informative error handling, and leaving unnecessary features enabled. Recommendations include removing unused features, sending secure headers, not using default configurations, and properly configuring robots.txt files. Links to additional resources on these topics are also provided.

2. Access 4.1.3 Verify that the principle of least privilege exists - users should only be able to access functions,
data files, URLs, controllers, services, and other resources, for which they possess specific
authorization. This implies protection against spoofing and elevation of privilege. C7
Access 4.1.4 Verify that the principle of deny by default exists whereby new users/roles start with minimal or
no permissions and users/roles do not receive access to new features until access is explicitly
assigned. C7
Access 4.1.5 Verify that access controls fail securely including when an exception occurs. C10
Access 4.2.1 Verify that sensitive data and APIs are protected against direct object attacks targeting creation,
reading, updating and deletion of records, such as creating or updating someone else's record,
viewing everyone's records, or deleting all records.
Access 4.3.2 Verify that directory browsing is disabled unless deliberately desired. Additionally, applications
should not allow discovery or disclosure of file or directory metadata, such as Thumbs.db,
.DS_Store, .git or .svn folders.
Config 14.2.2 Verify that all unneeded features, documentation, samples, configurations are removed, such as
sample applications, platform documentation, and default or example users.
Config 14.5.3 Verify that the cross-domain resource sharing (CORS) Access-Control-Allow-Origin header uses
a strict white-list of trusted domains to match against and does not support the "null" origin.
Config 14.4.4 Verify that all responses contain X-Content-Type-Options: nosniff.

3. Broken Access
Control
42%

4. Broken Access Control: Basics
Admin
User
Supervisor
Manager
User + Admin
Just User
User + Supervisor
User + Manager
web_app.com/admin/
web_app.com/user_info?user=1

5. 1. Modifying get-parameter in url
http://10.2.3.143/bWAPP/directory_traversal_2.php?directory=documents
http://10.2.0.170/bWAPP/directory_traversal_1.php?page=message.txt
2. Restrict folder access
http://10.2.3.143/bWAPP/restrict_folder_access.php
http://10.2.3.143/bWAPP/documents/ (login-guest)
3. Using malicious url as parameter
http://10.2.3.143/bWAPP/rlfi.php
http://www.c99php.com/shell/symlink.txt

6. What is confidential:
● Tokens
● API Keys
● Passwords
● Certificates

7. Strictly prohibited!!
bank_config =
{
acc_name = “admin”
auth_token = “Djkdfhsdjkf342RFfdgffhdsfg”
pass = “qwerty1234”
email = “admin@admin.com”
}

8. Strictly prohibited also!!

9. You can be vulnerable if:
● Bypass access control checks through URL changes
● Permission to change the primary key to someone else’s user
account, allowing you to view or edit someone else’s account
● Elevation of privilege. Acting as a user without being logged in,
or acting as an admin when logged in as a user.
● Browsing to authenticated pages as an unauthenticated user OR
to privileged pages as a standard user.

10. Recommendations
● Implement access controls once and repeatedly
use them throughout the application
● Accounts data changes should have only
account holders
● Close access to backup settings of
accounts, for example in git
● Log access control failures
● JWT tokens should be invalidated on the server
after logout

11. Security
Misconfiguration

12. Security Misconfiguration : Basics
Authorization
User
Pass
admin
admin
Open ports+server
configurations
allowing ddos
robots.txt

13. Example1- default credentials
Example2 - Robots.txt
Example3 - open ports (nmap), DDOS examples (slowloris)

14. You can be vulnerable if:
- Unnecessary features are enabled or installed (open ports, services,
pages, accounts or privileges)
- Default accounts and their passwords are still used and unchanged
- Overly Informative Error Handling
- For upgraded systems, latest security features are disabled or not
configured correctly
- The server does not send security headers or they are not set to
secure values
- Software is out of date or vulnerable

15. Recommendations
● A minimal platform w/o unnecessary features, components,
documentation etc. Remove or do not install unused
features and frameworks.
● Sending secure directives to clients (e.g. Secure Headers: HSTS,
HPKP, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, etc)
● Do not use default configurations
● For robots.txt:
○ close from crawling and indexing: admin page, search
results, registration page, login, reset password, etc
○ do not add robots.txt, if content is updated constantly
○ check for errors (Google Вебмастерс)

16. Link / Literature
https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control
https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html
https://www.immuniweb.com/vulnerability/improper-access-control.html
https://github.com/gkbrk/slowloris
http://blog.osinpaul.ru/2019/01/10/owasp-a6-security-misconfiguration-2017/
https://www.owasp.org/index.php/OWASP_Secure_Headers_Project
https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001)
https://www.owasp.org/index.php/Testing_for_configuration_management
https://www.owasp.org/index.php/OWASP_Secure_Headers_Project

17. Questions?