There are a few different ways to harden a web application against an injection attack. First, using parameterized procedures/queries to limit the ability of a potential attacker to change the intent of a query can be a good starting point. In addition, input validation should also be used. When at all possible, user input should be limited by using input fields like drop-downs or radio buttons to help validate the user-provided input. Another protection mechanism is to make sure that error reporting and handling is set up properly, so the details of database error messages are not passed to the web browser, revealing information that the attacker could use to design a successful attack.
In the OWASP documentation, Injection attacks were the most common. This was last updated in 2017. Which newer attacks/threats do you think would be included in the top 10? Do you think Injection attacks will still be the #1 threat in 2021?
There are thousands, and I think the OWASP Top 10 does a good job of giving business leaders the ability to focus on the riskiest vulnerabilities. However, one that the book mentioned that’s not in the OWASP Top 10 is the directory traversal (or dot-dot-slash) vulnerability. Attackers can exploit this to access files and directories stored on file system including application source code or configuration and critical system files.
Custom applications are likely easier to secure as they were developed specifically for the business and developers and security team are more entuned with the applications and vulnerabilities. An off the shelf software takes a one size fits all approach and is likely more susceptible to vulnerabilities.
There is often poor oversight when it comes to custom software, thus making it easier for attackers to exploit vulnerabilities or they could even write their own custom programs to execute on the victim’s server. Commercial software is robust with patches being released frequently to address any flaws that can be exploited at entity’s expense. As such, I would contend that commercial software is easier to secure than custom.
I would think the custom applications developed in house because hackers aren’t as familiar with the systems and program administered by the creators. Off-the-shelf programs are much more broad and hackers can easily purchase these applications on their own and figure out its weaknesses to try and penetrate the system through a commercial application. In addition, patches and updates for commercial software can be delayed from the time it is released until it is installed, vs custom applications can be implemented as soon as developers are done with it.
Off the shelf software from vendors that are well invested in security will always better than in-house developed code. Resources are often limited within the organization and if the organization is not a software developing organization, it will be difficult to make changes (patching) the existing, working code. Developing, testing, maintaining patches against new vulnerabilities is a costly initiative for any organization, if a solution exists from a different vendor, it will be an attractive cost-saving alternative for organizations.
Custom applications are easier to secure because they can tailor solutions according to your exact business process and needs. It is also easier to maintain. Compare with off-the-shelf software, it can quickly be changed depends on customers’ needs.
Great question Michael. I think the most relevant today is SQL injections because it is so prevalent in so many organizations and industries across the board. The least relevant I think is insufficient logging and monitoring because I think this issue can be more easily fixed than a SQL injection.
I think the most relevant security vulnerability today is SQL Injection because the vast majority of database management systems use SQL as the data access language. The lease relevant is Security Misconfigurations because human error is at the core of many misconfigurations. The risk can be prevented by proper employees training.
Broken access control is what I would put at the top of the list in terms of relevancy. Any organization knows by now they will have to protect the sensitive data, but ensuring the right people have the right access at the right time is equally important, but it’s hard for organizations to maintain without accurate and well-established controls.
Injections are something that is still a little bit over our heads in a technical sense. Personally, I think a lack of training and poor access control is very dangerous. More and more everyday people with no technical background are given more and more sensitive privileges. I can say personally I’ve had access to information that I had no business having.
An example of a buffer overflow attack is an attacker can overwrite a pointer (an object that points to another area in memory) and point it to an exploit payload, to gain control over the program.
For example, a buffer for log-in credentials designed to expect username and password inputs of 8 bytes, so if a transaction involves an input of 10 bytes (that is, 2 bytes more than expected), the program may write the excess data past the buffer boundary. The extra inputted overrun its bounds and copied over all other surrounding buffers in the vulnerable function, and caused the application to misbehave.
According to OWASP.org, when the code relies on external data to control its behavior. The code uses the gets() function to read any amount of data into the stack buffer. Since the amount of data read by this function cannot be limited, the security of the code depends on the number of characters entered by the user is always less than BUFSIZE characters.
I believe some common secure coding practices would include forcing traffic to use HTTPS, use encryption for sensitive information, and validate/sanitize all user input. Also, make sure authentication and access control is implemented and working properly.
One important secure coding practice is constant review of code. In my experience, it is hard to identify mistakes you make in your code. So, it is important to have a colleague review code periodically. They may be able to identify security issues you did not notice
One of the common security coding practices would be default deny. The decision on access rights is based on permission rather than exclusion. This means that by default, access is denied, and the protection scheme identifies the conditions under which access is allowed.
Some common secure coding practices include validating input (from untrusted data sources), practice defense in depth (control risk with multiple defensive approaches), and model threats (to anticipate the threats to which the software will be exposed).
How often is the OWASP Attack Surface Analysis Cheat Sheet updated to keep up with all the current and different types of cyberattacks? Why do you think the Attack Surface Analysis Cheat Sheet may need to be more frequently updated than before?
This should be updated continuously throughout the SDLC. The introduction of new technology, addition of a new web page or field on an existing web page; adding users/users group, etc., will change the landscape of the attack surface and therefore it should be continuously reviewed to ensure that all risks are identified and mitigated, as deemed necessary.
I do not personally use this, but my company uses it when conducting security reviews of vendors. Especially if the vendor is creating a custom application for us, it is important to see if they understand the common vulnerabilities and how to identify them before they are put into production.
My company does use OWASP Top 10 when performing vulnerability assessments on web applications. I have not used the software, but have looked over the results generated from the assessment.
If Hackers have access to your credit accounts by easily impersonating you, they can make illegal purchases, and open more credit card or bank accounts in your name.
If a hacker takes over an application they could retrieve, modify, or destroy information from the database. Also, the hacker could leverage vulnerabilities in the application to gain control of the server which could allow the hacker to gain control of other applications being hosted or move laterally in the network.
Hackers could infiltrate databases and steal PII that can then be sold on the black market for top dollars; use victim’s infrastructure to launch attacks on other targets; store illegal information – similar to the Titan incident; encrypt the victim’s infrastructure with ransomware which could leave them with a good pay day; exploit existing vulnerabilities in an APT; bragging rights for infiltrating robust security systems – to just name a few examples.
There are many ways hackers can benefit from taking over an application program: they could make unauthorized changes to the program, exploit weaknesses in the application that helps them gain access to the server, delete data from the application or hold the data in the application for ransom. When hackers are able to get control of an application programs, they can figure out how to best manipulate the information that they have to their own advantage.
It all boils down to data, depending on the application, sometimes it can be email data, PII, legal data, contractual data, tread secrets, credentials, etc.
A login screen bypass attack happens when the hacker skips the login page by typing a URL for a page after the login screen when the login screen appears. This would only work if an application is not coded or programmed correctly. This could be prevented by verifying that a program is properly coded. The program should be tested for this type of attack before going live.
VoIP provided organizations a number of advantages, however, what are some methods that you see in production to mitigate the risks highlighted in the text?
If you were responsible for application security at an organization and were only provided limited resources to be able to focus on 3 of the OWASP Top 10 risks, which 3 would you focus on first and why?
Does your organization complete an Attack Surface Analysis over your applications? If so, how often? What do you think is most useful about this exercise (regardless of if your organization competes this analysis or not).
Do you have any personal “favorite” security risks? I mentioned in one of the posts that injection, lack of logging and monitoring, and using components with known vulnerabilities were mine.
What are the best mitigation methods for hardening a web application for an injection attack?
There are a few different ways to harden a web application against an injection attack. First, using parameterized procedures/queries to limit the ability of a potential attacker to change the intent of a query can be a good starting point. In addition, input validation should also be used. When at all possible, user input should be limited by using input fields like drop-downs or radio buttons to help validate the user-provided input. Another protection mechanism is to make sure that error reporting and handling is set up properly, so the details of database error messages are not passed to the web browser, revealing information that the attacker could use to design a successful attack.
In the OWASP documentation, Injection attacks were the most common. This was last updated in 2017. Which newer attacks/threats do you think would be included in the top 10? Do you think Injection attacks will still be the #1 threat in 2021?
Instead of the top 10 OWASP, what other vulnerabilities can you think of?
There are thousands, and I think the OWASP Top 10 does a good job of giving business leaders the ability to focus on the riskiest vulnerabilities. However, one that the book mentioned that’s not in the OWASP Top 10 is the directory traversal (or dot-dot-slash) vulnerability. Attackers can exploit this to access files and directories stored on file system including application source code or configuration and critical system files.
Which are easier to secure: commercial off the shelf software or custom applications developed in house?
Custom applications are likely easier to secure as they were developed specifically for the business and developers and security team are more entuned with the applications and vulnerabilities. An off the shelf software takes a one size fits all approach and is likely more susceptible to vulnerabilities.
There is often poor oversight when it comes to custom software, thus making it easier for attackers to exploit vulnerabilities or they could even write their own custom programs to execute on the victim’s server. Commercial software is robust with patches being released frequently to address any flaws that can be exploited at entity’s expense. As such, I would contend that commercial software is easier to secure than custom.
I would think the custom applications developed in house because hackers aren’t as familiar with the systems and program administered by the creators. Off-the-shelf programs are much more broad and hackers can easily purchase these applications on their own and figure out its weaknesses to try and penetrate the system through a commercial application. In addition, patches and updates for commercial software can be delayed from the time it is released until it is installed, vs custom applications can be implemented as soon as developers are done with it.
Off the shelf software from vendors that are well invested in security will always better than in-house developed code. Resources are often limited within the organization and if the organization is not a software developing organization, it will be difficult to make changes (patching) the existing, working code. Developing, testing, maintaining patches against new vulnerabilities is a costly initiative for any organization, if a solution exists from a different vendor, it will be an attractive cost-saving alternative for organizations.
Custom applications are easier to secure because they can tailor solutions according to your exact business process and needs. It is also easier to maintain. Compare with off-the-shelf software, it can quickly be changed depends on customers’ needs.
Of the OWASP Top 10 application security vulnerabilities, which do you believe is the most relevant today? Which is the least relevant?
Great question Michael. I think the most relevant today is SQL injections because it is so prevalent in so many organizations and industries across the board. The least relevant I think is insufficient logging and monitoring because I think this issue can be more easily fixed than a SQL injection.
I think the most relevant security vulnerability today is SQL Injection because the vast majority of database management systems use SQL as the data access language. The lease relevant is Security Misconfigurations because human error is at the core of many misconfigurations. The risk can be prevented by proper employees training.
Broken access control is what I would put at the top of the list in terms of relevancy. Any organization knows by now they will have to protect the sensitive data, but ensuring the right people have the right access at the right time is equally important, but it’s hard for organizations to maintain without accurate and well-established controls.
Hi Mitchell,
Injections are something that is still a little bit over our heads in a technical sense. Personally, I think a lack of training and poor access control is very dangerous. More and more everyday people with no technical background are given more and more sensitive privileges. I can say personally I’ve had access to information that I had no business having.
What is an example of a buffer overflow attack?
An example of a buffer overflow attack is an attacker can overwrite a pointer (an object that points to another area in memory) and point it to an exploit payload, to gain control over the program.
For example, a buffer for log-in credentials designed to expect username and password inputs of 8 bytes, so if a transaction involves an input of 10 bytes (that is, 2 bytes more than expected), the program may write the excess data past the buffer boundary. The extra inputted overrun its bounds and copied over all other surrounding buffers in the vulnerable function, and caused the application to misbehave.
According to OWASP.org, when the code relies on external data to control its behavior. The code uses the gets() function to read any amount of data into the stack buffer. Since the amount of data read by this function cannot be limited, the security of the code depends on the number of characters entered by the user is always less than BUFSIZE characters.
What threat do you think will crack into the OWASP Top 10 list in 2020 and why?
What are some common secure coding practices?
I believe some common secure coding practices would include forcing traffic to use HTTPS, use encryption for sensitive information, and validate/sanitize all user input. Also, make sure authentication and access control is implemented and working properly.
One important secure coding practice is constant review of code. In my experience, it is hard to identify mistakes you make in your code. So, it is important to have a colleague review code periodically. They may be able to identify security issues you did not notice
One of the common security coding practices would be default deny. The decision on access rights is based on permission rather than exclusion. This means that by default, access is denied, and the protection scheme identifies the conditions under which access is allowed.
Some common secure coding practices include validating input (from untrusted data sources), practice defense in depth (control risk with multiple defensive approaches), and model threats (to anticipate the threats to which the software will be exposed).
How often is the OWASP Attack Surface Analysis Cheat Sheet updated to keep up with all the current and different types of cyberattacks? Why do you think the Attack Surface Analysis Cheat Sheet may need to be more frequently updated than before?
This should be updated continuously throughout the SDLC. The introduction of new technology, addition of a new web page or field on an existing web page; adding users/users group, etc., will change the landscape of the attack surface and therefore it should be continuously reviewed to ensure that all risks are identified and mitigated, as deemed necessary.
Could you provide examples of how your company is using the OWASP Top 10?
Does your company use the OWASP Top 10?
We use the OSAWP 10 principles in audits of our clients. I particularly see broken access management and cross site scripting frequently.
I do not personally use this, but my company uses it when conducting security reviews of vendors. Especially if the vendor is creating a custom application for us, it is important to see if they understand the common vulnerabilities and how to identify them before they are put into production.
My company does use OWASP Top 10 when performing vulnerability assessments on web applications. I have not used the software, but have looked over the results generated from the assessment.
What can hackers gain by taking over application programs?
If Hackers have access to your credit accounts by easily impersonating you, they can make illegal purchases, and open more credit card or bank accounts in your name.
If a hacker takes over an application they could retrieve, modify, or destroy information from the database. Also, the hacker could leverage vulnerabilities in the application to gain control of the server which could allow the hacker to gain control of other applications being hosted or move laterally in the network.
Hackers could infiltrate databases and steal PII that can then be sold on the black market for top dollars; use victim’s infrastructure to launch attacks on other targets; store illegal information – similar to the Titan incident; encrypt the victim’s infrastructure with ransomware which could leave them with a good pay day; exploit existing vulnerabilities in an APT; bragging rights for infiltrating robust security systems – to just name a few examples.
There are many ways hackers can benefit from taking over an application program: they could make unauthorized changes to the program, exploit weaknesses in the application that helps them gain access to the server, delete data from the application or hold the data in the application for ransom. When hackers are able to get control of an application programs, they can figure out how to best manipulate the information that they have to their own advantage.
It all boils down to data, depending on the application, sometimes it can be email data, PII, legal data, contractual data, tread secrets, credentials, etc.
What are the proper steps you should take to prevent a login screen bypass attack?
A login screen bypass attack happens when the hacker skips the login page by typing a URL for a page after the login screen when the login screen appears. This would only work if an application is not coded or programmed correctly. This could be prevented by verifying that a program is properly coded. The program should be tested for this type of attack before going live.
VoIP provided organizations a number of advantages, however, what are some methods that you see in production to mitigate the risks highlighted in the text?
If you were responsible for application security at an organization and were only provided limited resources to be able to focus on 3 of the OWASP Top 10 risks, which 3 would you focus on first and why?
Does your organization complete an Attack Surface Analysis over your applications? If so, how often? What do you think is most useful about this exercise (regardless of if your organization competes this analysis or not).
Do you have any personal “favorite” security risks? I mentioned in one of the posts that injection, lack of logging and monitoring, and using components with known vulnerabilities were mine.