A constant connection of society with the internet and modern technology allows more space for creativity in business than ever before- including the black market.
The rapid advancements in technology is a testament to innovators, however, security is falling apart severely.
Cybercriminals are carefully exploring new ways to intercept the most sensitive networks in the world. Safeguarding the business data is a growing challenge but awareness is the first step.
This blog describes the common reasons that lead to breaches and the top 10 security rules to ensure enterprise security.
Enterprise security implies protecting data and assets from unauthorized access to the system and platforms. It aims at reducing the risk and strengthening the company's defense system.
A few reasons for missing security implementation are-
The Open Web Application Security Project (OWASP) community has issued the guidelines that enterprises should follow during the software life cycle to ensure its security.
Besides, working with multinational enterprise clients, especially in a multi-vendor environment; there are certain security rules which need to be followed.
Here are the top 10 security rules that are critical for enterprise security-
a. Description: Session timeout represents the event occurring when a user does not perform any action on a web site during an interval (defined by the webserver).
b. Impact: This is the second important security risk, listed by OWASP. An attacker can try to steal and use an existing user session for getting all details and thus risks the user identity.
c. Remediation:
2. Password Policy
a. Description: Password policy entail a set of rules which are applied to boost security and ensure password protection.
b. Impact: An attacker can easily access the content of the password-protected resources to gain full control of the application.
c. Remediation:3. Cross-Site Scripting (XSS)
a. Description: XSS attacks are a type of client-side injection in which malicious scripts are injected into web browsers. The actual attack occurs when the user visits the web page or web application, resulting in the execution of malicious code.
b.Impact: It can be used to victimize a user or deface the website. The attacker can use these scripts to either redirect users to another site or access any cookies, session tokens, or other sensitive information retained by the browser and used within that site. These scripts can even rewrite the content of the HTML page.
c. Remediation:To prevent XSS security vulnerabilities,
4. HTML5 cross-origin resource sharing
a. Description: An HTML5 cross-origin resource sharing (CORS) policy allows controlled access to resources outside the domain. It controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy.
b. Key CORS Headers: There are several HTTP headers related to CORS, but the following three response headers are the most important for security-
c. Impact: If all domains are allowed by the policy, then other domains can potentially attack users of the application. If a user is logged in to the application and visits a domain allowed by the policy, then any malicious content running on that domain can potentially retrieve content from the application, and sometimes carry out actions within the security context of the logged-in user.
d. Remediation:
5. HTTP Verb Tampering
a. Description: HTTP Verb Tampering is an attack that exploits vulnerabilities in HTTP method authentication and access control mechanisms when APIs are exposed.
b. Impact: This attack can be performed by a malicious user who wants to exploit the application for their benefit or an attacker who wishes to attack a third person using a Man-in-the-middle attack. The attacker can also try any of the valid HTTP methods, such as HEAD, TRACE, TRACK, PUT, DELETE, and many more.
c. Remediation: Methods (GET, POST, PUT, PATCH, OPTIONS) which are being used and are needed in the API, should only be allowed in service.yml.
If any of the verbs are not used in a specific application then we should limit it.
6. Insecure Direct Object Reference
a. Description: A direct object reference is likely to occur when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key without any validation mechanism which allows attackers to manipulate these references to access unauthorized data.
b. Impact: An attacker can manipulate direct object references to access other objects without authorization unless an access control check is in place.
c. Remediation: Developers can use the following resources/points as a guide to preventing insecure direct object reference during the development phase itself.
7. Cookie with HttpOnly Flag Set / No Unprotected Cookie
a. Description: When a cookie is set with the HttpOnly flag, it instructs the browser that the cookie can only be accessed by the server and not by client-side scripts.
b. Impact: If the HttpOnly flag is not set, then sensitive information stored in the cookie may be exposed to unintended users. Also if the cookie is an authentication cookie, then not setting the HttpOnly flag may allow a malicious user to steal authentication data (e.g., a session ID) and assume the identity of the user.
c.Remediation: The secure flag should be set on all cookies that are used for transmitting sensitive data when accessing content over HTTPS. If cookies are used to transmit session tokens, then areas of the application that are accessed over HTTPS should employ their session handling mechanism, and the session tokens used should never be transmitted over unencrypted communications.
8. SSL cookie with the secure flag set
a. Description: HTTPS is a secure version of HTTP to achieve authentication & data integrity. A secure flag is an option that can be set by the application server when sending a new cookie to the user within an HTTP Response.
b. Impact: When HTTP is used, the cookie is sent in plaintext and hence the attacker eavesdropping on the communication channel between the browser and the server can grab the cookie and impersonate the user.
c. Remediation:
9. Header Injection
a. Description: HTTP response header injection vulnerabilities arise when user-supplied data is copied into a response header in an unsafe way.
b. Impact: An attacker can inject new HTTP headers and also by injecting an empty line; break out of the headers into the message body and write arbitrary content into the application's response.
c. Remediation: Applications should avoid copying user-controllable data into HTTP response headers
10. File Manipulation
a. Description:
File path manipulation vulnerabilities arise when user-controllable data is placed into a file or URL path that is used on the server to access local resources, which may be within or outside the webroot.
b. Impact:
An attacker can modify the file path to access different resources, which may contain sensitive information. Even where an attack is constrained within the webroot, it is often possible to retrieve items that are normally protected from direct access, such as application configuration files, the source code for server-executable scripts, or files with extensions that the webserver is not configured to serve directly.
c. Remediation: This can normally be achieved by referencing known files via an index number rather than their name.
Technology’s persistent march calls for better security practices to discourage intruders from breaking into the system and more resolute programming standards to lower the possibility of crippling outages.
Instead of just letting the technology hustle ahead of us and then trying to catch up in terms of privacy and security, enterprises should bake in these features into the system right from the beginning with smart coding.
Stay Safe!
Srijan takes security issues as a serious threat to organizations’ valuable assets and progress. And so, to mitigate the risk, it has been providing its clients with a solution to deal with it efficiently. You too can reach out to us for the same. Contact now!