The Open Web Application Security Project (OWASP) is a foundation that tries to improve web application security. This group lists the top 10 most common vulnerabilities that are impacting applications and provides information on each vulnerability such as the risk, how to mitigate the vulnerability, attack scenarios, and references. While reading this document I took notice how injection and broken authentication were the top 2 vulnerabilities in 2013 and are still the top 2 vulnerabilities four years later in the 2017 OWASP top 10. The number 1 vulnerability is injection which occurs when an application does not validate or sanitize data that was provided by the user. This data could possibly be database commands that would return information the user should not have access to, modify data, or delete data. The number 2 vulnerability is broken authentication which an attacker may gain access to an application by brute force, weak passwords, or possibly URL rewriting.
The OWASP Top 10 is always talked about (though people still leave those items as vulnerabilities in their applications and websites). What I find most helpful is that it’s not just a list of 10 application security risks. If you delve into each risk, there’s a breakdown of Exploitability, Prevalence, Detectability, Technical Impacts, and Business Impacts. Each category is given a rating. Importantly, there’s also a “how to prevent” section for each risk that mentions ways each one can be defended against. Considering the prevalence of things like SQL Injection attacks and the fact that the vulnerability is still so prevalent, it’s no surprise to me that injection was #1 in 2013 and 2017. I’m interested to see what the next iteration of the list looks like.
OWASP’s mission is to help organizations understand secure coding practices so their applications and APIs can be trusted. As the title implies, it lists 10 common application security risks. I found the +D section to be interesting, which gives developers tools and resources to use to encourage secure coding. It gives 5 sections: Application security requirements, application security architecture, standard security controls, secure development lifecycle, and application security education. I found the resources listed under the Application Security Education section to be most interesting, as it lists many helpful resources for developers. While many of the links were disabled now, the archived resources were interesting. For example, the OWASP WebGoat.NET site is an ASP.NET website that purposely has many vulnerabilities. This allows developers to see what certain vulnerabilities will do to their applications.
I think you point out several things that make the OWASP Top 10 most useful. It’s one thing to just put out a list of top application security risks and leave it at that. I think that’s what most people think the OWASP Top 10 is. But there’s also actionable tips and resources that can be used to mitigate risks and improve your web applications. And it’s useful for organizations of all sizes.
In OWASP Top 10 – 2017, I like how it should change between 2013 and 2017. It, not only list the top ten risks but also shows the explanation of the risk, vulnerabilities, the method of prevention, and lists different attack scenarios with references. One of the parts I find interest is sensitive data exposure. It usually is a manual attack, target on week key generation and management, and weak algorithm, weak password hashing storage techniques. The information typically likes sensitive personal information data such as health records, credentials, personal data, and credit card information should be protected. The company can check if the application vulnerable by ensuring the encryption is enforced and the sensitive data stored in a clear text such as backups; Classify data processed, stored, or transmitted by an application. Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs.
In the OWASP Top 10 Web Application Security Risks, the broken authentication and sensitive data exposure are ranked number two and number three. Broken authentication can expose credentials and enable brute force attacks. This is largely due to design and implementation flaws. However, sensitive data exposure has become a more impactful attack in recent years according to OWASP. “Weak algorithm, protocol, and cipher usage is common, particularly for weak password hashing storage techniques”.
Sensitive data exposure is definitely impactful. This is a result of not adequately protecting the database, and inadvertently exposing personal data which can lead to the attacker having access and stealing sensitive information such as bank account information, credit card numbers, and even usernames and passwords.
The fifth most critical application security vulnerability in 2017 was determined to the broken access control. Broadly, this vulnerability would consist of unauthorized individuals being able to manipulate the application to allow them to act as a user without properly authenticating, or to gain privileged permissions without logging in as an administrator. There are a variety of ways a broken access control can manifest, such as being vulnerable to SQL command injection to retrieve the target credentials, or to force browse to an administrative controls page that hasn’t been properly secured. These are difficult vulnerabilities to detect internally, because automated detection systems don’t have a way to test this. Additionally, developers often don’t test for access control vulnerabilities..
From the OWASP Top 10, I learned that it focuses on recognizing the most high-risk web application for most organizations. Each risk contain information about the likelihood and technical impact using the OWASP Risk rating methodology. By using OWASP Risk Assessment Framework’s Static Application Security Testing tool, companies are able to analyze their code quality and vulnerabilities. OWASP Risk Assessment Framework can be integrated into the DevSecOps toolchain to help developers to write and produce secure code. The OWASP method maps out how different paths using different applications could do different harm, each path represents a risk that either requires attention or could be neglected. Thus, orgs must evaluate the likelihood associated with each threat.
This document provides the list of the 10 most common application vulnerabilities and basic techniques to protect against these high-risk problem areas. Application security is no longer optional. Between increasing attacks and regulatory pressures, organizations must establish effective processes and capabilities for securing their applications and API. Achieving application security requires many different parts of an organization to work together efficiently, including software development, security audit, and executive management. Companies should adopt this document and start the process of ensuring that their web applications minimize the risks.
Important takeaways that I learned from the OWASP Top 10 are OWASP core principles of being free and easily accessible to any users. The Open Web Application Security Project or OWASP is an international non-profit organization dedicated to web application security. OWASP is periodically updated to report concerns for web application security, focusing on the 10 most essential cyber risks. According to the report, the most common types of application security risk are Injection, Broken Authentication, sensitive data Exposure, XML External Entities, and Broken Access Control. For example, In an injection cyberattack occurs when untrusted data is sent to an interpreter as a command. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without the proper authorization protocols.
An interesting takeaway from this reading is continuous application security testing. Continuous testing involves understanding the threat model which allows prioritization of testing; using testing approaches that is compatible with people, processes and tools used in the SDLC, trying to impose extra steps may create conflicts that hinder testing process; testing approach should involve the simplest, fastest and most accurate techniques to verify each requirement; focusing on the most important program and then expanding verification over time and finally clearly communicating testing results to ensure that it can be understood by technical and non-technical stakeholders. Considering the dynamic risk environment, it makes sense that testing is done continuously across the SDLC, versus once or twice per year.
Lakshmi, I also thought this was a good point from the reading. Based on how quickly risks change in today’s environment, testing has to be ongoing and not just periodically, and it is critical that it is performed across the SDLC. However, I cannot help but wonder how many organizations really do a good job with the continuous threat modeling and testing. I would imagine not nearly enough organizations have dedicated time and resources to making sure this happens.
Sensitive data exposure is a an interesting OWASP top 10 risk;. PII and HIPPA information, may not be properly protected all the time. The key, in my opinion, is to learn your customers and understand what information you truly need to keep. Then ensure that you are securing this information. If the information is not needed get rid of it.
Great point that you bring up regarding OWASP. I am with you on the importance of knowing your customer and understanding what information you really need to maintain in your information system. I think that many of the data breaches could be avoided if organizations learned how to destroy unnecessary data within there information technology servers and networks.
This reading detailed the 10 most critical web application security risk. Of the 10, the one that stood our most to me is number 5 broken access control. The reading states access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification or destruction of all data, or performing a business function outside of the limits of the user. Some vulnerabilities are bypassing access control checks by modifying the URL and allowing the primary key to be changed to another users record, permitting viewing or editing someone else’s account.
Broken access control seems extremely dangerous to me as well. Like you described, being able to alter the primary key to any users primary key is extremely dangerous. I’ve also seen stories in the past where hackers have found ways to login to accounts without using a password. Some sites have vulnerabilities where there are ways to bypass having to enter passwords all together. This is why access control is so important
I agree with the point you make. Access Control is very very very important. Ensuring proper access control could virtually shut the door on a nefarious actor who is trying to work their way through a network.
The purpose of OWASP is to help website users protect their web applications from any vulnerabilities, and arrange the most important security risks that affects web applications. Sensitive Data Exposure (#3) struck me due to three sensitive groups that should be kept confidential and protected at all times: financial, healthcare, and personally identifiable information. Documents exposed to attackers can be exploited for medical information, identity theft, credit card fraud, and other offenses for their personal gain.
My key takeaway from reading the OWASP Top 10 was that security misconfiguration is the most commonly seen issue in application security. Not only are security configuration controls needed at initial deployment of an application, but also an ongoing process to manage patches and upgrades is necessary to maintain secure configuration. I thought this was interesting because it seems to be a repeat theme that has come up in several recent readings, as far as the necessity of having good application fixes (whether for patches or upgrades) but also the challenges presented by keeping up with third-party application updates. Another element I found interesting from the reading is that the OWASP is almost entirely composed of volunteers. This is pretty impressive, that there is a network of volunteers that is dedicated to keeping up with these top 10 web application security risks, as well as the variety of tools, standards, and cheat sheets that they have made available at no cost.
I thought the OWASP risk assessment methodology was interesting. The three likelihood factors that were used were prevalence, detectability, and ease of exploit and were rated on a risk scale of 1 – 3 (low to high). Once the numeric value of the likelihood factors are determined fir each weakness, they are multipled by the average impact factor (technical impact) for each item to determine the overall risk rating. The section also reiterates time and time again, that these are detailed with generalities rather than specificas and that each organization is unique and the employees/IT professionals know their organization best and are most knowledgable around the threat landscape of the organization, criticality of application and data, and the system specs and how it runs. This is a little different from the risk assessment that I typically see, but it makes sense given this is a ranking of risks related to application security and is meant to be general in nature. An organization should use this as a strating point for consideration and further build out the applicable risks.
The three vulnerabilities on this list that I am choosing to talk about are Injection, using components with known vulnerabilities, and insufficient logging and monitoring. As an IT Auditor, the latter two are the most important. Injection is what intrigues me the most. It’s fascinating to me how something as open-sourced as SQL can be manipulated using special commands. Components with known vulnerabilities would mainly pertain to software that is no longer being supported. For example, Microsoft is no longer patching or supporting Windows XP. Fingers crossed they stop supporting Internet Explorer so all the browser apps at work can be migrated to a real web browser. Insufficient logging and monitoring are very self-explanatory. Edits and activity should all be logged and attached to a specific user, not only for auditing purposes but also to discourage any foul play.
The Open Web Application Security Project (OWASP) is a foundation that tries to improve web application security. This group lists the top 10 most common vulnerabilities that are impacting applications and provides information on each vulnerability such as the risk, how to mitigate the vulnerability, attack scenarios, and references. While reading this document I took notice how injection and broken authentication were the top 2 vulnerabilities in 2013 and are still the top 2 vulnerabilities four years later in the 2017 OWASP top 10. The number 1 vulnerability is injection which occurs when an application does not validate or sanitize data that was provided by the user. This data could possibly be database commands that would return information the user should not have access to, modify data, or delete data. The number 2 vulnerability is broken authentication which an attacker may gain access to an application by brute force, weak passwords, or possibly URL rewriting.
The OWASP Top 10 is always talked about (though people still leave those items as vulnerabilities in their applications and websites). What I find most helpful is that it’s not just a list of 10 application security risks. If you delve into each risk, there’s a breakdown of Exploitability, Prevalence, Detectability, Technical Impacts, and Business Impacts. Each category is given a rating. Importantly, there’s also a “how to prevent” section for each risk that mentions ways each one can be defended against. Considering the prevalence of things like SQL Injection attacks and the fact that the vulnerability is still so prevalent, it’s no surprise to me that injection was #1 in 2013 and 2017. I’m interested to see what the next iteration of the list looks like.
OWASP’s mission is to help organizations understand secure coding practices so their applications and APIs can be trusted. As the title implies, it lists 10 common application security risks. I found the +D section to be interesting, which gives developers tools and resources to use to encourage secure coding. It gives 5 sections: Application security requirements, application security architecture, standard security controls, secure development lifecycle, and application security education. I found the resources listed under the Application Security Education section to be most interesting, as it lists many helpful resources for developers. While many of the links were disabled now, the archived resources were interesting. For example, the OWASP WebGoat.NET site is an ASP.NET website that purposely has many vulnerabilities. This allows developers to see what certain vulnerabilities will do to their applications.
I think you point out several things that make the OWASP Top 10 most useful. It’s one thing to just put out a list of top application security risks and leave it at that. I think that’s what most people think the OWASP Top 10 is. But there’s also actionable tips and resources that can be used to mitigate risks and improve your web applications. And it’s useful for organizations of all sizes.
In OWASP Top 10 – 2017, I like how it should change between 2013 and 2017. It, not only list the top ten risks but also shows the explanation of the risk, vulnerabilities, the method of prevention, and lists different attack scenarios with references. One of the parts I find interest is sensitive data exposure. It usually is a manual attack, target on week key generation and management, and weak algorithm, weak password hashing storage techniques. The information typically likes sensitive personal information data such as health records, credentials, personal data, and credit card information should be protected. The company can check if the application vulnerable by ensuring the encryption is enforced and the sensitive data stored in a clear text such as backups; Classify data processed, stored, or transmitted by an application. Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs.
In the OWASP Top 10 Web Application Security Risks, the broken authentication and sensitive data exposure are ranked number two and number three. Broken authentication can expose credentials and enable brute force attacks. This is largely due to design and implementation flaws. However, sensitive data exposure has become a more impactful attack in recent years according to OWASP. “Weak algorithm, protocol, and cipher usage is common, particularly for weak password hashing storage techniques”.
Sensitive data exposure is definitely impactful. This is a result of not adequately protecting the database, and inadvertently exposing personal data which can lead to the attacker having access and stealing sensitive information such as bank account information, credit card numbers, and even usernames and passwords.
The fifth most critical application security vulnerability in 2017 was determined to the broken access control. Broadly, this vulnerability would consist of unauthorized individuals being able to manipulate the application to allow them to act as a user without properly authenticating, or to gain privileged permissions without logging in as an administrator. There are a variety of ways a broken access control can manifest, such as being vulnerable to SQL command injection to retrieve the target credentials, or to force browse to an administrative controls page that hasn’t been properly secured. These are difficult vulnerabilities to detect internally, because automated detection systems don’t have a way to test this. Additionally, developers often don’t test for access control vulnerabilities..
From the OWASP Top 10, I learned that it focuses on recognizing the most high-risk web application for most organizations. Each risk contain information about the likelihood and technical impact using the OWASP Risk rating methodology. By using OWASP Risk Assessment Framework’s Static Application Security Testing tool, companies are able to analyze their code quality and vulnerabilities. OWASP Risk Assessment Framework can be integrated into the DevSecOps toolchain to help developers to write and produce secure code. The OWASP method maps out how different paths using different applications could do different harm, each path represents a risk that either requires attention or could be neglected. Thus, orgs must evaluate the likelihood associated with each threat.
This document provides the list of the 10 most common application vulnerabilities and basic techniques to protect against these high-risk problem areas. Application security is no longer optional. Between increasing attacks and regulatory pressures, organizations must establish effective processes and capabilities for securing their applications and API. Achieving application security requires many different parts of an organization to work together efficiently, including software development, security audit, and executive management. Companies should adopt this document and start the process of ensuring that their web applications minimize the risks.
Important takeaways that I learned from the OWASP Top 10 are OWASP core principles of being free and easily accessible to any users. The Open Web Application Security Project or OWASP is an international non-profit organization dedicated to web application security. OWASP is periodically updated to report concerns for web application security, focusing on the 10 most essential cyber risks. According to the report, the most common types of application security risk are Injection, Broken Authentication, sensitive data Exposure, XML External Entities, and Broken Access Control. For example, In an injection cyberattack occurs when untrusted data is sent to an interpreter as a command. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without the proper authorization protocols.
An interesting takeaway from this reading is continuous application security testing. Continuous testing involves understanding the threat model which allows prioritization of testing; using testing approaches that is compatible with people, processes and tools used in the SDLC, trying to impose extra steps may create conflicts that hinder testing process; testing approach should involve the simplest, fastest and most accurate techniques to verify each requirement; focusing on the most important program and then expanding verification over time and finally clearly communicating testing results to ensure that it can be understood by technical and non-technical stakeholders. Considering the dynamic risk environment, it makes sense that testing is done continuously across the SDLC, versus once or twice per year.
Lakshmi, I also thought this was a good point from the reading. Based on how quickly risks change in today’s environment, testing has to be ongoing and not just periodically, and it is critical that it is performed across the SDLC. However, I cannot help but wonder how many organizations really do a good job with the continuous threat modeling and testing. I would imagine not nearly enough organizations have dedicated time and resources to making sure this happens.
Sensitive data exposure is a an interesting OWASP top 10 risk;. PII and HIPPA information, may not be properly protected all the time. The key, in my opinion, is to learn your customers and understand what information you truly need to keep. Then ensure that you are securing this information. If the information is not needed get rid of it.
Great point that you bring up regarding OWASP. I am with you on the importance of knowing your customer and understanding what information you really need to maintain in your information system. I think that many of the data breaches could be avoided if organizations learned how to destroy unnecessary data within there information technology servers and networks.
This reading detailed the 10 most critical web application security risk. Of the 10, the one that stood our most to me is number 5 broken access control. The reading states access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification or destruction of all data, or performing a business function outside of the limits of the user. Some vulnerabilities are bypassing access control checks by modifying the URL and allowing the primary key to be changed to another users record, permitting viewing or editing someone else’s account.
Broken access control seems extremely dangerous to me as well. Like you described, being able to alter the primary key to any users primary key is extremely dangerous. I’ve also seen stories in the past where hackers have found ways to login to accounts without using a password. Some sites have vulnerabilities where there are ways to bypass having to enter passwords all together. This is why access control is so important
Hi Ashleigh,
I agree with the point you make. Access Control is very very very important. Ensuring proper access control could virtually shut the door on a nefarious actor who is trying to work their way through a network.
The purpose of OWASP is to help website users protect their web applications from any vulnerabilities, and arrange the most important security risks that affects web applications. Sensitive Data Exposure (#3) struck me due to three sensitive groups that should be kept confidential and protected at all times: financial, healthcare, and personally identifiable information. Documents exposed to attackers can be exploited for medical information, identity theft, credit card fraud, and other offenses for their personal gain.
My key takeaway from reading the OWASP Top 10 was that security misconfiguration is the most commonly seen issue in application security. Not only are security configuration controls needed at initial deployment of an application, but also an ongoing process to manage patches and upgrades is necessary to maintain secure configuration. I thought this was interesting because it seems to be a repeat theme that has come up in several recent readings, as far as the necessity of having good application fixes (whether for patches or upgrades) but also the challenges presented by keeping up with third-party application updates. Another element I found interesting from the reading is that the OWASP is almost entirely composed of volunteers. This is pretty impressive, that there is a network of volunteers that is dedicated to keeping up with these top 10 web application security risks, as well as the variety of tools, standards, and cheat sheets that they have made available at no cost.
I thought the OWASP risk assessment methodology was interesting. The three likelihood factors that were used were prevalence, detectability, and ease of exploit and were rated on a risk scale of 1 – 3 (low to high). Once the numeric value of the likelihood factors are determined fir each weakness, they are multipled by the average impact factor (technical impact) for each item to determine the overall risk rating. The section also reiterates time and time again, that these are detailed with generalities rather than specificas and that each organization is unique and the employees/IT professionals know their organization best and are most knowledgable around the threat landscape of the organization, criticality of application and data, and the system specs and how it runs. This is a little different from the risk assessment that I typically see, but it makes sense given this is a ranking of risks related to application security and is meant to be general in nature. An organization should use this as a strating point for consideration and further build out the applicable risks.
The three vulnerabilities on this list that I am choosing to talk about are Injection, using components with known vulnerabilities, and insufficient logging and monitoring. As an IT Auditor, the latter two are the most important. Injection is what intrigues me the most. It’s fascinating to me how something as open-sourced as SQL can be manipulated using special commands. Components with known vulnerabilities would mainly pertain to software that is no longer being supported. For example, Microsoft is no longer patching or supporting Windows XP. Fingers crossed they stop supporting Internet Explorer so all the browser apps at work can be migrated to a real web browser. Insufficient logging and monitoring are very self-explanatory. Edits and activity should all be logged and attached to a specific user, not only for auditing purposes but also to discourage any foul play.