SlideShare a Scribd company logo

Owasp top 10 2017

•Download as PPTX, PDF•
•
I
ibrahimumer2

The OWASP Top 10 is a list published by OWASP that contains the ten most critical security vulnerabilities that threaten web applications. The document discusses the top 10 vulnerabilities including injection, broken authentication, sensitive data exposure, XML external entities, broken access control, security misconfiguration, cross-site scripting, insecure deserialization, using components with known vulnerabilities, and insufficient logging and monitoring. Prevention methods are provided for each vulnerability.

Related slideshows

Owasp Top 10
Owasp Top 10Owasp Top 10
Owasp Top 10
 
OWASP Top 10 2017 - New Vulnerabilities
OWASP Top 10 2017 - New VulnerabilitiesOWASP Top 10 2017 - New Vulnerabilities
OWASP Top 10 2017 - New Vulnerabilities
 
OWASP Top 10 Vulnerabilities 2017- AppTrana
OWASP Top 10 Vulnerabilities 2017- AppTranaOWASP Top 10 Vulnerabilities 2017- AppTrana
OWASP Top 10 Vulnerabilities 2017- AppTrana
 
1 of 23
OWASP Top 10 Internship Program
OWASP Top 10 • Open Web Application Security Project (OWASP) is non-profit entity and an open community dedicated to enabling organizations to develop, purchase, and maintain applications and APIs that can be trusted. • OWASP published the 5th revision of their popular OWASP Top 10 list in November 2017. The list contains the ten most critical security vulnerabilities that threaten modern web applications • OWASP Top 10 has been revised several times to reflect changes in the way developers protect their web applications, and the methods attackers use to target them.
1: Injection • Injection is most common security vulnerabilities. • Injection flaws such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. Examples: • SQL : writing different SQL commands on the username field (SELECT * from table) • OS: executing a router’s operating system's built-in ping command with the hostname the user supplied, potentially opening a security flaw.
Prevention • Using Query parameterization which separate statement from any kind of parameters. • Validate user input , preventing unnecessary symbols ( example * on username field) • Limiting maximum information on the database to be fetched. • Building web app using proper control. • Using web application firewall
2: Broken Authentication • Authentication in web applications is mostly used to control users' access to specific information. • The most common security risks related to authentication and session management are: password theft, stealing session tokens and impersonating legitimate users.
Broken Authentication allows users (bad users) getting into web apps without proper credential. The attacker may use: • Credential stuffing: known usernames and passwords. • Automated attacks: random usernames and passwords. • Default username & passwords: like Username Admin and Password Admin • Social engineering: by tricking the victim.
Prevention • Multifactor authentication: using multiple authentications like biometrics, tokens and fingerprint verification in addition to simple password. • Password checking: checking password with in database with top 10,000 passwords on the internet and informing the user. • recommend users to create strong passwords. • Limit failed login • Creating new session on the server side • Using web application firewall
3: Sensitive Data Exposure • Sensitive data stored in databases (or anywhere else) should be well protected. • Credit card details, social security numbers and other sensitive customer details should be encrypted at rest when stored in a database, even if they are not directly accessible through a web application. • The same applies for sensitive data that is transmitted to and from the web application, such as credentials or payment details. Such information should be also be transmitted over a secure and encrypted layer.
Prevention • Encrypting all pages with sensitive data using strong cipher (TLS, SSL) • Classify data and apply control to the sensitive data separately. • Encrypted data at rest when stored in a database, even if they are not directly accessible through a web application. • Avoid storing sensitive data unless it is absolutely necessary. • Avoiding file upload flow • Using web application firewall
4: XML External Entities (XEE) • XML gives you a way to define your own entities in order to make coding and configuration easier. An example (in an XML file) where this is necessary is in a customizable configuration file in a web application. • XML Entities are like variables: they will expand to a defined value once they are processed by the XML parser. • However: there is one problem. When it is possible to pass XML documents to a parser that supports external entities, attackers can retrieve content from a website behind a firewall, issue requests to certain services, and even disclose the content of files stored on the server. Because entities can be referenced within entity definitions. • attackers can craft an XML document that contains only 10 entities, but that will eventually expand to a billion entities once it is parsed. This is also known as the 'Billion Laughs Attack'.
Prevention • Disable XEE completely or partially per parsor. • Implement server side input validation. • Using source code analysis tools (SCAST) • Using Dynamic application security testing (DAST) • Using web application firewall.
5: Broken Access Control • Access Control is simply the process of granting and denying access to a user. • Different roles exits in different web app, these roles will have different level of access. Example Admin and normal user. • Broken Access Control refers to restrictions that are not properly enforced. It occurs for example when authenticated users without administrative authority can create new administrator accounts. • A common example of such vulnerability is an admin panel that relies heavily on JavaScript to execute certain actions, such as the creation of an admin account.
Prevention • Enforcing to trusted server side code. • Doing a lot of manual testing before publishing the web application. • Deny everything by default, and only give access to who need to use it. • Implement access control once and reuse it across the web application. • Logging failures and alerting admins whenever happens • Least privilege: giving the minimum extent they need to do the job or function and beyond that only giving access for the minimum amount of time they need to do the job. • Using web application firewall.
6: Security Misconfiguration Web application security is not just about secure web application coding. To ensure the security of a web application, it is also important to: • secure the configuration of the web server, • secure the operating system of the web server. • ensure that the server is always updated with the latest security patches. The same applies for the web frameworks used on the web server, such as PHP and NET, Database servers like oracles.
Prevention • Check default configuration and turn off ports and Delete features we don’t use. Default accounts example username: Admin and password: Admin • Don’t overshare information. Example: don’t project any information on error page , like disclosure of software versions. This may allow attackers to get vulnerabilities for your software easily. • Update softwares (example apache, oracle)with latest security patches regularly. • Use automated scanning capabilities.
7: Cross-site Scripting (XSS) • A cross-site scripting (XSS) vulnerability allows hackers to inject malicious client-side script, in a website or web application, that is later executed by the victims. Typically, cross-site scripting attacks are used to bypass access controls and to impersonate legitimate users, such as the web application administrator. • Attackers sends code they want your browser to execute in order to send them your secret (valuable) staff. • Attackers may try to steal cookies by sending post(<script>………….</script>) to the web application to get the cookies of the victim by making the victim send it to the attacker.
Prevention • Using latest and modern browsers and update regularly, since better browsers have improved detection of scripts with in HTML, on the victims browser. • When building web application, we need to separate untrusted data from Active browser content.
8: Insecure Deserialization • Insecure deserialization is the process of changing byte streams (which were created by serialization by saving and persisting the state of the object) in to the original object. • During this process , the attacker can modify the byte stream, When it is deserialized, Attack happens. • The malicious attacker (invalidated user) can give himself Admin role through Insecure deserialization.
Prevention • not to accept serialized objects from untrusted sources. • Isolating and running code that deserializes in low privilege environments when possible. • Logging deserialization exceptions and failures, such as where the incoming type is not the expected type, or the deserialization throws exceptions. • Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize.
9: Using Components with Known Vulnerabilities • successful attacks happen When the attacker exploited a known vulnerability in an outdated software that was still being used. • attacks happen When Administrators fail to regularly update all of the software used on their web servers and by web applications with the latest, most secure and most stable versions.
Prevention • Update the software immediately, whenever updates available. • Plan for the known components. • Monitor, patch, and configure the software regularly.
10: Insufficient Logging and Monitoring • Insufficient Logging and Monitoring refers to the inability to log and detect hacking attempts and breaches. • Statistics from 2016 show that, on average, it took an organization 191 days to detect a data breach! It is possible to reduce this time greatly, and prevent breaches before they happen, if sufficient logging and monitoring take place.
Prevention • Logging every failed login , warning, error messages etc. • Log files must not contain information, if accessed by attackers • Make it sufficient content, to help us find out pattern of failed logins. Example when someone trying dictionary attack. • Storing log files in good formats • Integrity control (checking) on log file. • Having response plan.

More Related Content

Owasp top 10 2017

  • 2. OWASP Top 10 • Open Web Application Security Project (OWASP) is non-profit entity and an open community dedicated to enabling organizations to develop, purchase, and maintain applications and APIs that can be trusted. • OWASP published the 5th revision of their popular OWASP Top 10 list in November 2017. The list contains the ten most critical security vulnerabilities that threaten modern web applications • OWASP Top 10 has been revised several times to reflect changes in the way developers protect their web applications, and the methods attackers use to target them.
  • 3. 1: Injection • Injection is most common security vulnerabilities. • Injection flaws such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. Examples: • SQL : writing different SQL commands on the username field (SELECT * from table) • OS: executing a router’s operating system's built-in ping command with the hostname the user supplied, potentially opening a security flaw.
  • 4. Prevention • Using Query parameterization which separate statement from any kind of parameters. • Validate user input , preventing unnecessary symbols ( example * on username field) • Limiting maximum information on the database to be fetched. • Building web app using proper control. • Using web application firewall
  • 5. 2: Broken Authentication • Authentication in web applications is mostly used to control users' access to specific information. • The most common security risks related to authentication and session management are: password theft, stealing session tokens and impersonating legitimate users.
  • 6. Broken Authentication allows users (bad users) getting into web apps without proper credential. The attacker may use: • Credential stuffing: known usernames and passwords. • Automated attacks: random usernames and passwords. • Default username & passwords: like Username Admin and Password Admin • Social engineering: by tricking the victim.
  • 7. Prevention • Multifactor authentication: using multiple authentications like biometrics, tokens and fingerprint verification in addition to simple password. • Password checking: checking password with in database with top 10,000 passwords on the internet and informing the user. • recommend users to create strong passwords. • Limit failed login • Creating new session on the server side • Using web application firewall
  • 8. 3: Sensitive Data Exposure • Sensitive data stored in databases (or anywhere else) should be well protected. • Credit card details, social security numbers and other sensitive customer details should be encrypted at rest when stored in a database, even if they are not directly accessible through a web application. • The same applies for sensitive data that is transmitted to and from the web application, such as credentials or payment details. Such information should be also be transmitted over a secure and encrypted layer.
  • 9. Prevention • Encrypting all pages with sensitive data using strong cipher (TLS, SSL) • Classify data and apply control to the sensitive data separately. • Encrypted data at rest when stored in a database, even if they are not directly accessible through a web application. • Avoid storing sensitive data unless it is absolutely necessary. • Avoiding file upload flow • Using web application firewall
  • 10. 4: XML External Entities (XEE) • XML gives you a way to define your own entities in order to make coding and configuration easier. An example (in an XML file) where this is necessary is in a customizable configuration file in a web application. • XML Entities are like variables: they will expand to a defined value once they are processed by the XML parser. • However: there is one problem. When it is possible to pass XML documents to a parser that supports external entities, attackers can retrieve content from a website behind a firewall, issue requests to certain services, and even disclose the content of files stored on the server. Because entities can be referenced within entity definitions. • attackers can craft an XML document that contains only 10 entities, but that will eventually expand to a billion entities once it is parsed. This is also known as the 'Billion Laughs Attack'.
  • 11. Prevention • Disable XEE completely or partially per parsor. • Implement server side input validation. • Using source code analysis tools (SCAST) • Using Dynamic application security testing (DAST) • Using web application firewall.
  • 12. 5: Broken Access Control • Access Control is simply the process of granting and denying access to a user. • Different roles exits in different web app, these roles will have different level of access. Example Admin and normal user. • Broken Access Control refers to restrictions that are not properly enforced. It occurs for example when authenticated users without administrative authority can create new administrator accounts. • A common example of such vulnerability is an admin panel that relies heavily on JavaScript to execute certain actions, such as the creation of an admin account.
  • 13. Prevention • Enforcing to trusted server side code. • Doing a lot of manual testing before publishing the web application. • Deny everything by default, and only give access to who need to use it. • Implement access control once and reuse it across the web application. • Logging failures and alerting admins whenever happens • Least privilege: giving the minimum extent they need to do the job or function and beyond that only giving access for the minimum amount of time they need to do the job. • Using web application firewall.
  • 14. 6: Security Misconfiguration Web application security is not just about secure web application coding. To ensure the security of a web application, it is also important to: • secure the configuration of the web server, • secure the operating system of the web server. • ensure that the server is always updated with the latest security patches. The same applies for the web frameworks used on the web server, such as PHP and NET, Database servers like oracles.
  • 15. Prevention • Check default configuration and turn off ports and Delete features we don’t use. Default accounts example username: Admin and password: Admin • Don’t overshare information. Example: don’t project any information on error page , like disclosure of software versions. This may allow attackers to get vulnerabilities for your software easily. • Update softwares (example apache, oracle)with latest security patches regularly. • Use automated scanning capabilities.
  • 16. 7: Cross-site Scripting (XSS) • A cross-site scripting (XSS) vulnerability allows hackers to inject malicious client-side script, in a website or web application, that is later executed by the victims. Typically, cross-site scripting attacks are used to bypass access controls and to impersonate legitimate users, such as the web application administrator. • Attackers sends code they want your browser to execute in order to send them your secret (valuable) staff. • Attackers may try to steal cookies by sending post(<script>………….</script>) to the web application to get the cookies of the victim by making the victim send it to the attacker.
  • 17. Prevention • Using latest and modern browsers and update regularly, since better browsers have improved detection of scripts with in HTML, on the victims browser. • When building web application, we need to separate untrusted data from Active browser content.
  • 18. 8: Insecure Deserialization • Insecure deserialization is the process of changing byte streams (which were created by serialization by saving and persisting the state of the object) in to the original object. • During this process , the attacker can modify the byte stream, When it is deserialized, Attack happens. • The malicious attacker (invalidated user) can give himself Admin role through Insecure deserialization.
  • 19. Prevention • not to accept serialized objects from untrusted sources. • Isolating and running code that deserializes in low privilege environments when possible. • Logging deserialization exceptions and failures, such as where the incoming type is not the expected type, or the deserialization throws exceptions. • Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize.
  • 20. 9: Using Components with Known Vulnerabilities • successful attacks happen When the attacker exploited a known vulnerability in an outdated software that was still being used. • attacks happen When Administrators fail to regularly update all of the software used on their web servers and by web applications with the latest, most secure and most stable versions.
  • 21. Prevention • Update the software immediately, whenever updates available. • Plan for the known components. • Monitor, patch, and configure the software regularly.
  • 22. 10: Insufficient Logging and Monitoring • Insufficient Logging and Monitoring refers to the inability to log and detect hacking attempts and breaches. • Statistics from 2016 show that, on average, it took an organization 191 days to detect a data breach! It is possible to reduce this time greatly, and prevent breaches before they happen, if sufficient logging and monitoring take place.
  • 23. Prevention • Logging every failed login , warning, error messages etc. • Log files must not contain information, if accessed by attackers • Make it sufficient content, to help us find out pattern of failed logins. Example when someone trying dictionary attack. • Storing log files in good formats • Integrity control (checking) on log file. • Having response plan.