How should you protect your system against increasing security risks?


OWASP (Open Web Application Security Project) is a non-profit organization that deals with web application security and publishes articles and applications on this subject. Workcube follows OWASP and regularly engages in improvement activities.


Possible security problems and ways to avoid these problems are listed in the OWASP TOP 10 list as follows.

  1. Injection
  2. Broken Authentication
  3. Sensitive Data Exposure
  4. XML External Entities(XXE)
  5. Broken Access Control
  6. Security Misconfiguration
  7. Cross-Site Scripting (XSS)
  8. Insecure Deserialization
  9. Using Compenents With Known Vulnerabilities
  10. Insefficient Logging & Monitoring

A1. Injection Vulnerabilities
Injection vulnerabilities are realized by sending a part of a command or query to the interpreter in the data received from the user. Injection vulnerabilities are a common vulnerability, especially in SQL Injection web applications. There are multiple types of injections: SQL, LDAP, XPath or NoSQL, XML parsers, OS commands, SMTP headers, expression languages and ORM queries, and more. Injection causes data leakage or direct loss.

How to Protect?

The use of interpreters should be avoided. If a request is to be sent to the interpreter, the API should be used. eg. Powerful query and object relational mapping libraries (ORMs) are available.

Use “whitelist” for server-side login validation. This is not a complete defense as many apps require special characters like text fields or APIs for mobile apps. Strong-type queries should replace pointers when stored procedures are called.

The entered data needs to be validated. (Limit or sql controls must be used for SQL injections. Database access rights must be done correctly.


A2. Broken Authentication 
It is the type of vulnerability that attackers use to seize user information, passwords, sessions using brute force(Brute Force Attack). Attackers can detect broken authentication using manual tool or exploit password list and dictionary attacks using automated tool. Attackers can only reach a few important accounts and achieve their goals. For example, if they access the Admin account, they can do great damage with this user.

How to Protect?

Automation should be avoided when performing multi-factor authentication, if possible. For Admin/Administrator users, no credentials should be added. Strong password controls are mandatory. Password length, complexity must comply with modern password policies.

The same messages must be used for all results. Need to be sure of the difficulty of API paths. Failed logins should be capped. All information needs to be logged. Administrators need to be alerted when brute force or any attack is detected.

It is mandatory to generate as many random session tokens as possible and to apply session tokens properly.


A3. Sensitive Data Exposure

This type of vulnerability is caused by not encrypting data or using old, default, exposed encryption algorithms. Credit card information, passwords, personal records, company documents and many other important information must be encrypted.

At the same time, even if the information is encrypted while recording on the server side, if the information goes unencrypted while being transferred from the client to the server, this creates a vulnerability. Therefore, encryption should be used during the transfer as well as server-side encryption.

How to Protect?

Strong encryption algorithms should be used instead of old encryption algorithms. Never publish your private keys on unsecured channels. Instead of using insecure cleartext protocols such as http, ftp, smtp, SSL protocols such as https, ftps, smtps should be used that transfer encrypted.

Under PCI data security standard requirement 3, you must protect the card holder data. The best practice is to never store unnecessary data.


A4. Xml External Entities (XXE)
This vulnerability is caused by outdated or misconfigured XML pars. By using this vulnerability, attackers can send a malicious xml file to the server, read files from the server, run code and perform a dos attack.

How to Protect?
Use the less complex JSON format if possible. Keep XML related libraries updated. Turning off the XML External Entity property would be helpful. The "whilelisting" control must be done by the server.


A5. Broken Access Control
Saldırganlar bu zaafiyeti kullanarak izni olmayan dosyalara erişebilir, yetkisi olmayan fonksiyonları kullanabilir, diğer kullanıcıların verilerine erişebilir ya da yetkileri değiştirebilir.

How to protect?
Other data than general data should be blocked by default. It is a must that the permission control mechanism is made properly and used in other places and that the Server directory listing is disabled. It is imperative that incorrect accesses are logged and reported to the system administrator, and that the administrator installs them regularly.


A6. Security Misconfiguration
It is a type of vulnerability that occurs as a result of incorrect or incomplete service settings. Security misconfiguration can happen on any application stack, including network services, platform, web server, application server, database, frameworks, custom code, and preinstalled virtual machines, containers, or storage. 

How is it Protected?
Remove unused features or frameworks. Perform checks to verify the effectiveness of configurations and settings in all environments. Be sure to change the default passwords.


A7. Cross Site Scripting (XSS)
It occurs as a result of sending the data received from the user as an html response without checking and filtering. There are three forms of XSS that typically target users' browsers:

  • Reflected XSS: It is the ability to run JS code in the instant user browser of the data received from the user. Reflected XSS is usually caused by clicking on malicious links.
  • Stored XSS: Generally considered a high or critical risk. Because it is recorded by the server and the code runs every time that page is called.
  • DOM XSS: Dynamically defined attacker-controllable data in JS Frameworks, single-page applications, and APIs. 

How to protect?
It is necessary to validate the incoming data, avoiding the untrusted HTML request in the HTML output. Implementing context-aware encoding will reduce the security risk.


A8. Insecure Deserialization
This vulnerability occurs as a result of deserialization of untrusted malicious input from the user. Therefore, it is necessary to check the data from the user.

How to protect?
Integrity checks such as digital signatures should be enforced on serialized objects. Type constraints must be applied before the object is created. It is essential to isolate and run serializing code in low-privileged environments whenever possible.

It is necessary to log, monitor or restrict outgoing serial network connections from the server or container, or ban in case of anomalies. If similar series are coming from the same user, a warning should be given and banned.


A9. Using Components with Known Vulnerabilities
While it is easy to find pre-written vulnerabilities for many known vulnerabilities, other vulnerabilities require extensive effort to open a specific vulnerability. This type of vulnerability occurs as a result of using old versions of services, applications, plug-ins with known exploits. After the attackers find the versions of these services, they can use known exploits to hijack the application/server. That poses a huge risk.

How to protect?
It is necessary to keep the operating system, services, applications up-to-date, and remove unused services. It is essential to regularly check for new vulnerabilities and make appropriate patches. Get components only from official sources over secure links. Prefer signed packages to reduce the chance of adding a modified, malicious component.


A10. Insufficient Logging and Monitoring

Inadequate recording and use of views is the root cause of almost every major event. Diaries/logs should be reviewed after a strategy penetration test to determine if you have adequate monitoring or not. Testers' actions must be sufficiently recorded to understand what harm they could do.

Most successful attacks start with vulnerability research. Allowing such probes to continue increases the probability of successful exploitation to almost 100%.

How to protect?
Ensure that all logins, access control failures, and server-side login validation errors can be logged with sufficient user context to identify suspicious or malicious accounts and are retained for a sufficient period of time to allow for delayed forensic analysis.
With a centralized log management solutions, logs must be created in an easily consumable (?) format. Effective monitoring and alerting should be done so that suspicious activities are detected and responded to in a timely manner. Ensure high-value transactions have audit trails.


Compiling and translating using OWASP sources

Feedback

Did you find this content helpful?