OWASP – Security Misconfiguration

Overview: Security misconfigurations are security controls that are inaccurately configured or
left insecure, putting your systems and data at risk such as any poorly documented
configuration changes, or a technical issue across any component in your endpoints and default settings.

We can detect security misconfigurations in web applications using following test cases:

1)  EXPOSED FILES AND DIRECTORIES: Files and directories when left unprotected may allow hackers to force browse the application and help them access the restricted files in root/server directory.

We can use Burp engagement tools and google dorking to find out exposed files and directories.

Example attack scenario:

site: testphp.vulnweb.com ext:bak

This search query in google will yield a list of files ending in “.bak “, an extension commonly associated with backup files and restrict search results to the domain of the target site:testphp.vulnweb.com.

Prevention: 

Before pushing your changes to the live/production server you should use a test or staging environment. keep backup files on your web server out of the directory you have configured your webserver to serve. Configure your WordPress files permissions to prohibit access to the web server’s user, so that even in case of an event of a misconfiguration, the webserver will not expose the file to a client requesting it. Encryption of database backups is a good idea also the encryption key should not be accessible by the web server’s user.

Directory listings & Missing Index Files

A directory listing is a type of Web page that displays the directory contents that exist on a Web server when there is no index file in a specific website directory. File (.htaccess) protects directory contents from unauthorized viewing but can be seen and read when there is server misconfiguration.

Example attack scenario:

In a vulnerable website when a user makes a request www.vulnweb.com/admin/, the response from the server displays the directory content of the directory admin, as seen in the below screenshot.

In the screenshot you can see that in the admin directory there is a sub-directory called backup, which might include enough information for an attacker to craft an attack.

Misconfiguration of the web server has led the attacker to display the whole list of files in the backup directory such as password files, database files, FTP logs, and PHP scripts which was not intended for public view.

Prevention: 

No sensitive information should be disclosed. Restrict or disable directory listings from the web server configuration. On an Apache Web server, you can disable directory listings by placing a dash or minus sign before the word Indexes in the httpd.conf file (Options-Indexes followSymLinksMultiViews).

2) DEFAULT ACCOUNTS / PASSWORDS ARE ENABLED: It is a very common security misconfiguration where the attacker gains unauthorized access to the system using vendor-supplied defaults for system accounts and passwords.

Since default credentials are often bound to administrative accounts attackers use the following common Username/Passwords in authentication guessing attacks:

username

password

admin, administrator, root

admin, administrator, root, password, {company name}, {NULL}

{NULL}

{NULL}

Operator, backup

Operator, backup, {NULL}

test, test1, qa

Test, test1, qa, {NULL}

{company name}

{company name}, password, {NULL}

demo, guest, private

demo, guest, private, {NULL}

{known username}

{known username}, {NULL}

Prevention:

Change Default Passwords and Use Unique Default Passwords: Before deploying the system on an untrusted network such as the internet, default passwords must be changed. Systems should be designed to use unique default passwords.
Force the Default Password Changes: The system should be designed so that it requires a password change the first time a default password is used.

3) OUTDATED SOFTWARE/LIBRARIES

Vendors usually release upgrades for their open-source software, fixing gaps or bugs but fail to update the application with the available upgrades which gives a chance for attackers to gain unauthorized access. Use of third-party JavaScript libraries can introduce a range of XSS vulnerabilities. Few library vulnerabilities expose every application that imports the library while some may affect only applications that use certain library features.

Example attack scenario:

www.vulnerableweb.com -> view page source -> ctrl+f: bootstrap, jquery -> library version exposed -> find exploits for outdated libraries

Below is the screenshot of outdated libraries and their vulnerabilities.

Prevention:

Ensure to apply all available security updates regularly, especially when using third-party code, since the updates usually contain patches or fixes for any vulnerabilities that were detected recently. Remove the libraries that are no longer used.

4) ERROR HANDLING AND STACK TRACES

Improper error handling reveals the users overly informative error messages that includes sensitive information about its environment, users, or associated data. It leads to stack traces.

A stack trace is a report/long error message which leaks information about program subroutines. Attacker uses this information to gain access to potentially sensitive information such as: database versions, table names, code filenames, physical file paths of relevant files, server version etc. A stack trace is not a vulnerability but make customers assume the site is broken and worry about whether their transaction will work, or perhaps assume that the site has been hacked.

Example attack scenario:

www.vulnerableweb.com -> tamper the input to the vulnerable web application by sending invalid data input or insert illegal characters to the URL or the HTTP request -> Observe whether any underlying technology, IP address, internal file path, stack trace, and SQL queries are revealed in the error message

Below are screen shots of error messages:


Prevention:

Exception handling should be done internally and should not display errors which leak potentially sensitive information to a user.

Turn off stack traces on production servers before the programmer/administrator moves them into production after debugging the crashes.

5) MISSING SECURITY HEADERS

Security headers: They are directives used by web applications to configure security defenses in browsers. Clickjacking or XSS vulnerabilities can arise due to missing security headers such as X-Frame-Options and X-XSS-Protection response headers.

CLICKJACKING

Clickjacking (UI redress attack) is an attack/malicious technique of tricking a user into clicking a webpage element which is invisible or disguised as another element, thus potentially revealing sensitive information or make users to visit malicious web pages, download malware, transfer money or purchase products online. A site is vulnerable to clickjacking if the http://www.target.site page is successfully loaded within an iframe and the iframe is overlaid on top of the user’s anticipated decoy web page content. 

Example attack scenario:

www.target.site -> use clickjacking test code and try to open target site with an iframe.

Below is the screenshot of target site loaded in an iframe:

X-FRAME-OPTIONS HEADER

X-Frame-Options response header is passed as part of the HTTP response of a web page and prevents the site from clickjacking attacks by defining whether a browser should be allowed to render a page in a <FRAME> or <IFRAME> tag.

X-Frame-Options header allows following 3 types of values:

  • DENY: it is the most secure option which prevents any use of the current page in an iframe
  • SAMEORIGIN: allows the current page to be displayed in an iframe, but only within the current domain
  • ALLOW-FROM URI: allows the current page to be rendered in an I frame, but only that is originated from specified URI e.g.,example.com/frame-page. This directive has now become obsolete and not supported by modern browser.

X-XSS-PROTECTION HEADER

The X-XSS-Protection header is a HTTP response header featured in modern web browsers like Internet Explorer 8+, Chrome, and Safari that instructs the browser to stops pages from loading when they detect cross-site scripting (XSS) attacks.

X-XSS-Protection header allows following 4 types of values:

  • 0: It disables XSS filtering
  • 1: it is a default value; enables the X-XSS-Protection
  • 1; mode=block: it enables XSS filtering. If the browser detects an attack, it will prevent rendering of the page.
  • 1; report=<reporting-URI>: it enables XSS filtering. If the page detects an attack, it will sanitize the page and will be reported by report-URI directive.

Example attack scenario:

www.vulnerableweb.com -> right click -> select Inspect to open the developer tools -> Select Network tab -> Reload the page, select any HTTP request on the left panel, and the HTTP headers will be displayed on the right panel -> observe if any security headers are missing in response headers

Below is the screenshot of the response headers of the target site where security headers are missing:

Prevention:

Content Security Policy (CSP): It is a detection and prevention mechanism that provides an additional layer of protection from cross-site scripting (XSS) and clickjacking. By defining the appropriate CSP directive in the HTTP response header CSP can limit which data sources are allowed by a web application. Syntax of CSP is Content-Security-Policy: policy.

To protect against clickjacking, frame-ancestors directive must be incorporated in the application’s Content Security Policy. The frame-ancestors ‘none’ is like the X-Frame-Options deny directive and the frame-ancestors ‘self’ is like the X-Frame-Options same origin directive.

6) VERSION DISCLOSURE OR SENSITIVE INFO LEAK IN RESPONSE HEADERS

The Server header describes the software used by the server application that handled the request. Any detailed information such as name or version in this header can expose the server to attackers, and attackers use this information in this header to gain a greater understanding of the systems in use, find vulnerabilities easily and potentially develop further attacks targeted at the specific version of the server.

Example attack scenario:

www.vulnerableweb.com -> right click -> select Inspect to open the developer tools -> Select Network tab -> Reload the page, select any HTTP request on the left panel, and the HTTP headers will be displayed on the right panel -> observe server header and x-powered by response header.

Prevention:

Configure the webserver to stop sending detailed information in the Server header of its HTTP response.

-To fix server version disclosure in Apache, add below lines to Apache configuration file:

ServerTokens Prod

ServerSignature Off

-To fix server version disclosure in Nginx, add below line to nginx.conf file:

server_tokens off

The X-Powered-By response header describes the technologies used by the webserver. Any information in this header exposes the server to attackers, and attackers use this information in this header to find vulnerabilities easily.

Sruthi Buddharaju

Security Blogger & Infosec Professional

Leave a Reply

Your email address will not be published. Required fields are marked *