Forced Browser Vulnerability
Most applications require authentication for gaining access to restricted information or perform tasks. If adequate security is not in place, malicious users can circumvent the authentication process and gain access to these pages by simply skipping the login page and directly calling an internal page that is supposed to be accessed only after authentication has been performed. By directly browsing to the below listed pages without logging in, we are able to access and view its content without logging into the application.
Solution :
- Implement session management to ensure that only users logged into the system and with appropriate access levels are allowed access to the file.
- Check for the AUTH token to ensure only proper users logged into the system.
🤫 Wanna know deep dive JavaScript stuff on modern web applications and how are they maintained in large environments🤯. Check out below link for JavaScript related articles
Bypass IP restrictions
Some web applications implement IP-based protection rules that restrict users from accessing particular pages of an application if their IP addresses are not in the allowed list. These rules are used as an access control mechanism.
In here, we are able to bypass the whitelisted IP by X-Forwarded-For header
Attackers will use VPN and get different IP and then also they will get their response back.
Solution :
- X-Forwarded-For HTTP header should not be used for any Access Control List (ACL) checks because it can be spoofed by attackers. Use the real IP address for this type of restrictions.
- Add IP validation in the backend code if IP whitelisted list is maintained.
In-secure HTTP Method is Enabled
HTTP Methods such as TRACK, TRACE, DEBUG, PUT, DELETE, OPTIONS are intended for debugging or testing purposes. Production environments that allow these HTTP methods can be vulnerable to a range of attacks that are facilitated by these HTTP methods.
Solution:
- Possibly disable the above descripted HTTP methods in production
SSL not enforced
SSL is an encryption protocol that is based on a chain of trust between users, browsers, and certificate authorities. For compatibility purposes, browsers and SSL certificates support a wide range of encryption algorithms.
Using a non-SSL page for transmitting sensitive parameter makes it vulnerable to network sniffing as data is sent in cleartext. An attacker can thus obtain users credentials and in-turn compromises his account.
Solution:
It is recommended, to enforce the application to use SSL for every request.
Server Remote Version or Server Name Disclosure
Lets say I am hosting an backend app in Nginx . As we know NGINX is a free, open-source, high performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server. NGINX is known for its high performance, stability, rich feature set, simple configuration, and low resource consumption. An attacker can search for specific security vulnerabilities for the version of NGINX identified within the
SERVER header.
Solution:
Configure your web server to prevent information leakage from the SERVER header of its HTTP response
Cross Origin Resource Sharing misconfigured
Cross-origin resource sharing (CORS) is a mechanism that allows web page to make XMLHttpRequests to another domain. CORS defines a way in which the browser and the server can interact to determine whether or not to allow the cross-origin request. In this case, a web client can put any value into the Origin request HTTP header in
order to force web application to provide it the target resource content.
Solution:
An Access-Control-Allow-Origin header should not allow with *(wildcard) that allows all
domains
Several Security Headers
When a user tries to access a page, his browser requests it from a web server. The server then responds with the content along with appropriate HTTP Response Headers which contain meta data, status error codes, cache rules and so on. A big subset of those headers are security headers which instruct your browser exactly how to behave when it handles your websites content and data. HTTP security headers are a fundamental part of website security. Upon implementation, they protect you against the types of attacks that your site is most likely to come across. These headers protect against XSS, code injection, clickjacking, etc.
HTTP Strict-Transport-Security : The HTTP Strict Transport Security (HSTS) header is a mechanism that web sites have to communicate to the web browsers that all traffic exchanged with a given domain must always be sent over https, this will help protect
the information from being passed over unencrypted requests.
Content-Security-Policy : The content-security-policy HTTP header provides an additional layer of security. The HTTP Content Security Policy response header gives website admins a sense of control by giving them the authority to restrict the resources a user is allowed to load within site. In other words, you can whitelist your sites content sources.
X-XSS-Protection : This header is used to configure the built in reflective XSS protection found in Internet Explorer, Chrome and Safari (Webkit). Valid settings for the header are 0, which disables the protection, 1 which enables the protection and 1; mode=block which tells the browser to block the response if it detects an attack rather
than sanitizing the script.
X-Frame-Options: The X-Frame-Options header (RFC), or XFO header, protects your visitors against clickjacking attacks. An attacker can load up an iframe on their site and set your site as the source, it's quite easy: . Using some crafty CSS they can hide your site in the background and create some genuine looking overlays. When your visitors click on what they think is a harmless link, they're actually clicking on links on your website in the background.
Conclusion:
🤫 Wanna know deep dive JavaScript stuff on modern web applications and how are they maintained in large environments🤯. Check out below link for JavaScript related articles and if you really liked it clap and subscribe.
You can catch me up on other platforms too
Top comments (0)