In the world of internet the common problem is security of the application, hackers are trying to inject malwares or Trojans to the web applications. Web application attacks are now most frequent happens in the internet world. Yet many organizations struggle to implement an application security program because they simply don’t know where to start.
Every vibrant technology marketplace needs an unbiased source of information on best practices as well as an active body advocating open standards. In the Application Security space, one of those groups is the Open Web Application Security Project
Setting policies based on eliminating OWASP Top 10 vulnerabilities is an excellent starting point.
What is OWASP?
OWASP in full Open web application security project. OWASP is a non-profit organization dedicated to providing unbiased, practical information about application security. OWASP provides free resources related to web security methodologies, articles, documentations, tools and technologies. Owasp seeks to educate designers, developers, architects and business owners about the risk associated with the most common web application security vulnerabilities.
OWASP, which supports both open source and commercial security products, has become known as a forum in which information technology professionals can network and build expertise. The organization publishes a popular Top Ten list that explains the most dangerous Web application security flaws and provides recommendations for dealing with those flaws.
OWASP tools, document and code library projects are organized into three categories, tools and documents that can be used to find security-related design and implementation flaws, tools and documents that can be used to guard against security-related design and implementation flaws and tools and documents that can be used to add security-related activities into the application life cycle management.(ALM)
OWASP, top 10 vulnerabilities in 2017.
OWASP collecting data from 40+ submissions from the firm that specializes in application security and industry survey that was completed by over 500 individuals. After gathering these risks from hundreds of organizations and over lakhs of real world application and API’s. Select top 10 items among the risks according to that in combination with consensus estimates of exploitability, detectability and impact.
The following identifies each of the OWASP Top 10 Web Application Security Risks, and offers solutions and best practices to prevent or remediate them.
Injection flaws, such as SQL injection, LDAP injection, and CRLF injection, occur when an attacker sends un-trusted data to an interpreter that is executed as a command without proper authorization. Application security testing can easily detect injection flaws. Developers should use parameterized queries when coding to prevent injection flaws.
- BROKEN AUTHENTICATION and SESSION MANAGEMENT
Incorrect implemented Application, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.
Multi-factor authentication, such as FIDO or dedicated apps, reduces the risk of compromised accounts.
- SENSITIVE DATA EXPOSURE
Sensitive data exposures may occur when security controls – such as HTTPS – are not implemented correctly. Most of the web applications and APIs do not properly protect. Sensitive data, such as financial, PII and healthcare. Attackers may steal or modify such weakly protected data to conduct, identity theft, credit card fraud or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires extra precautions when exchanged with the browser.
Encryption of data at rest and in transit can help you comply with data protection regulations.
4. XML EXTERNAL ENTITIES (XXE)
Poorly configured XML processors evaluate external entity references within XML documents. Attackers can use external entities for attacks including remote code execution, and to disclose internal files and SMB file shares.
Static application security testing (SAST) can discover this issue by inspecting dependencies and configuration.
5.BROKEN ACCESS CONTROL
Improperly configured or missing restrictions on authenticated users allow them to access unauthorized functionality or data, such as accessing other users’ accounts, viewing sensitive documents, and modifying data and access rights.
Penetration testing is essential for detecting non-functional access controls; other testing methods only detect where access controls are missing.
6. SECURITY MISCONFIGURATION
This risk refers to improper implementation of controls intended to keep application data safe, such as mis configuration of security headers, error messages containing sensitive information (information leakage), and not patching or upgrading systems, frameworks, and components. A strong security requires secure and good configuration server, database, custom code and kept up to date. If the proper configuration is not set then the attacker can access privileged data.
Dynamic application security testing (DAST) can detect misconfigurations, such as leaky APIs.
7. CROSS-SITE SCRIPTING
Cross-site scripting (XSS) flaws give attackers the capability to inject client-side scripts into the application, for example, to redirect users to malicious websites. XSS flaws occur whenever an application includes untrusted data in a web page without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites. Apps that allow user input without having full control over output may be highly at risk to XSS attacks. When an XSS attack is successful, attackers are able to cause serious damage to websites and have the ability to drag users on to other websites. Other known kinds of XSS attacks are Stored XSS, DOM Based XSS, and Reflected XSS.
Developer training complements security testing to help programmers prevent cross-site scripting with best coding best practices, such as encoding data and input validation.
8. INSECURE DESERIALIZATION
Insecure deserialization flaws can enable an attacker to execute code in the application remotely, tamper or delete serialized (written to disk) objects, conduct injection attacks, and elevate privileges. Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage or to send as part of communications. Deserialization is the reverse of that process – taking data structured from some format, and rebuilding it into an object. Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.
Application security tools can detect deserialization flaws but penetration testing is frequently needed to validate the problem.
9. USING COMPONENTS WITH KNOWN VULNERABILITIES
Developers frequently don’t know which open source and third-party components are in their applications, making it difficult to update components when new vulnerabilities are discovered. Attackers can exploit an insecure component to take over the server or steal sensitive data.
Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.
By taking using components with known vulnerabilities, attackers can take advantage of that are easily attempt an SQLi and an XSS (among other attack methods) to attempt to take over an occupy the app.
Software composition analysis conducted at the same time as static analysis can identify insecure versions of components.
10. INSUFFICIENT LOGGING AND MONITORING
The time to detect a breach is frequently measured in weeks or months. Insufficient logging and ineffective integration with security incident response systems allow attackers to pivot to other systems and maintain persistent threats. Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
Think like an attacker and use pen testing to find out if you have sufficient monitoring; examine your logs after pen testing.
These are the OWASP TOP 10 2017 as a security person you have to know about these.
The resource has taken from https://www.owasp.org