Why SQL Injections Are The Cockroaches of the AppSec World (and how CISOs can eradicate them once and for all)
There's a well-known theory that cockroaches can survive basically anything - even a nuclear explosion. While that theory only rings true to a point, their simple body composition makes them extremely hardy for their size, and difficult to eradicate under most conditions.
I've been thinking... if cockroaches had an equivalent in the digital world, it would have to be SQL injection (SQLi) vulnerabilities in code. This has been a known vulnerability for more than twenty years, yet organizations fall victim to them time and time again. The widespread, costly attack on Target was the result of SQL injection, as was an instance of election hacking in Illinois in which 200,000 voter records were exposed, prompting the FBI to recommend all IT admins work quickly to strengthen their security practices.
Imperva's Hacker Intelligence Initiative Report revealed that between 2005 and 2011, SQLi attacks were used in 83% of all reported data breaches. Today, injection vulnerabilities remain the number-one threat in the OWASP Top 10. They are relatively simple, yet they just won't die.
It seems ridiculous that this same vulnerability is still appearing in a significant number of application security scans. We know how it operates, and we know how to stop it. How is this possible? The truth is, our software security has a vast amount of room for improvement.
Veracode's State of Software Security Report - based on 400,000 application scans in 2017 " revealed an alarming statistic: just 30% of applications passed OWASP Top 10 policy. This has been a consistent theme over the past five years, with SQL injections appearing in almost 1 in 3 newly scanned applications. This is evidence of an endemic issue; we are not learning from our mistakes, and CISOs seem to face an uphill battle in being able to procure enough security talent. Typically, the ratio of AppSec specialists to developers is an inadequate 1:100.
Why is software security on life support?
It's no secret that specialist security talent is scarce, but we must also pay attention to the fact that developers are not fixing issues as they arise, and are quite clearly ill-equipped to not introduce vulnerabilities in the first place. In the same Veracode report, it was divulged that there were documented mitigations for just 14.4% of all development vulnerabilities. In other words, most vulnerabilities were submitted without development mitigation. Fewer than one-third of vulnerabilities were closed in the first 90 days, and 42% of vulnerabilities were never closed within the development period.
I speak to security professionals, CISOs and CEOs all the time, and anecdotally, I've become aware that many companies become so frustrated with the number of vulnerabilities found that can't be mitigated (in addition to the scourge known as false positives), that they stop scanning for them altogether, cross their fingers and hoping for the best.
Why do AppSec professionals let this happen?
Make no mistake: AppSec people are painfully aware of problems in code. After all, that's one of their core skills that makes them such a valuable team resource. However, they are often hamstrung by several factors.
For instance, an AppSec manager will find an issue and ask the developer, "can you fix the code?". The answer to this important question differs from organization to organization, but in general, the developer is so stretched meeting strict feature delivery sprints that they simply don't have the time to fix these problems, nor decent tools to help them. AppSec professionals themselves might be able to identify vulnerabilities, but they often don't have the skills and/or access to remediate them on the spot.
We must also realize that for every problem, there is a process of needing to find a solution, implement it, and then test it. For even the slightest issue found in the code, the time it can take to fix, not mention the resources required, is immense. There are over 700 vulnerabilities that can be introduced into software, and it's simply impossible for any one person to be able to defend against them all. It is for this reason that most companies stick to following the OWASP Top 10 only. All the while, developers keep building features and in turn, they keep introducing vulnerabilities into the code they write.
What is the solution?
The simple fact is, we don't give our developers the tools and training to foster secure coding success. There are no regulations that force organizations to ensure developers possess adequate security skills, and it's a sad reality that most universities and internships don't prepare junior developers to code securely, either.
When someone wants to fly a plane, there is a very rigorous process that ensures training, practical experience, medical checks, safety knowledge and exams before they are able to fly. No-one would dare imagine that they would be let loose in the sky without this extensive preparation and validation of skills, yet this is what happens on a day-to-day basis with code writing.
We need to spend the time to educate developers on writing secure code. However, in todays world, where software development is fast-paced as well as good developers and security professionals existing in short supply, it never seems to be a priority. It's time we changed the conversation.
A recent headline from the World Economic Forum screamed: "There can be no digital economy without security", with the accompanying content arguing the need for security to be a core part of any digital transformation strategy. "Security is what protects businesses, allowing them to innovate, build new products and services. Beyond a defensive role, security provides businesses with a strategic growth advantage."
Improving secure coding skills and outcomes will add a powerful layer of cyber protection for organizations, assisting them in creating better, faster code. Developers don't need to become security experts, but they must be empowered positively and practically to be the first line of defense against cyberattacks. Developers can be the next security and innovation heroes. They are very clever people, they are creative problem-solvers, and generally keen to build their skills. Play to their strengths with the specialized training they deserve, and commit to a higher software security standard. Read our white paper to find out more.
When someone wants to fly a plane, there is a very rigorous process that ensures training, practical experience, medical checks, safety knowledge and exams before they are able to fly. No-one would dare imagine that they would be let loose in the sky without this extensive preparation and validation of skills, yet this is what happens on a day-to-day basis with code writing.
There's a well-known theory that cockroaches can survive basically anything - even a nuclear explosion.
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoMatias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
There's a well-known theory that cockroaches can survive basically anything - even a nuclear explosion. While that theory only rings true to a point, their simple body composition makes them extremely hardy for their size, and difficult to eradicate under most conditions.
I've been thinking... if cockroaches had an equivalent in the digital world, it would have to be SQL injection (SQLi) vulnerabilities in code. This has been a known vulnerability for more than twenty years, yet organizations fall victim to them time and time again. The widespread, costly attack on Target was the result of SQL injection, as was an instance of election hacking in Illinois in which 200,000 voter records were exposed, prompting the FBI to recommend all IT admins work quickly to strengthen their security practices.
Imperva's Hacker Intelligence Initiative Report revealed that between 2005 and 2011, SQLi attacks were used in 83% of all reported data breaches. Today, injection vulnerabilities remain the number-one threat in the OWASP Top 10. They are relatively simple, yet they just won't die.
It seems ridiculous that this same vulnerability is still appearing in a significant number of application security scans. We know how it operates, and we know how to stop it. How is this possible? The truth is, our software security has a vast amount of room for improvement.
Veracode's State of Software Security Report - based on 400,000 application scans in 2017 " revealed an alarming statistic: just 30% of applications passed OWASP Top 10 policy. This has been a consistent theme over the past five years, with SQL injections appearing in almost 1 in 3 newly scanned applications. This is evidence of an endemic issue; we are not learning from our mistakes, and CISOs seem to face an uphill battle in being able to procure enough security talent. Typically, the ratio of AppSec specialists to developers is an inadequate 1:100.
Why is software security on life support?
It's no secret that specialist security talent is scarce, but we must also pay attention to the fact that developers are not fixing issues as they arise, and are quite clearly ill-equipped to not introduce vulnerabilities in the first place. In the same Veracode report, it was divulged that there were documented mitigations for just 14.4% of all development vulnerabilities. In other words, most vulnerabilities were submitted without development mitigation. Fewer than one-third of vulnerabilities were closed in the first 90 days, and 42% of vulnerabilities were never closed within the development period.
I speak to security professionals, CISOs and CEOs all the time, and anecdotally, I've become aware that many companies become so frustrated with the number of vulnerabilities found that can't be mitigated (in addition to the scourge known as false positives), that they stop scanning for them altogether, cross their fingers and hoping for the best.
Why do AppSec professionals let this happen?
Make no mistake: AppSec people are painfully aware of problems in code. After all, that's one of their core skills that makes them such a valuable team resource. However, they are often hamstrung by several factors.
For instance, an AppSec manager will find an issue and ask the developer, "can you fix the code?". The answer to this important question differs from organization to organization, but in general, the developer is so stretched meeting strict feature delivery sprints that they simply don't have the time to fix these problems, nor decent tools to help them. AppSec professionals themselves might be able to identify vulnerabilities, but they often don't have the skills and/or access to remediate them on the spot.
We must also realize that for every problem, there is a process of needing to find a solution, implement it, and then test it. For even the slightest issue found in the code, the time it can take to fix, not mention the resources required, is immense. There are over 700 vulnerabilities that can be introduced into software, and it's simply impossible for any one person to be able to defend against them all. It is for this reason that most companies stick to following the OWASP Top 10 only. All the while, developers keep building features and in turn, they keep introducing vulnerabilities into the code they write.
What is the solution?
The simple fact is, we don't give our developers the tools and training to foster secure coding success. There are no regulations that force organizations to ensure developers possess adequate security skills, and it's a sad reality that most universities and internships don't prepare junior developers to code securely, either.
When someone wants to fly a plane, there is a very rigorous process that ensures training, practical experience, medical checks, safety knowledge and exams before they are able to fly. No-one would dare imagine that they would be let loose in the sky without this extensive preparation and validation of skills, yet this is what happens on a day-to-day basis with code writing.
We need to spend the time to educate developers on writing secure code. However, in todays world, where software development is fast-paced as well as good developers and security professionals existing in short supply, it never seems to be a priority. It's time we changed the conversation.
A recent headline from the World Economic Forum screamed: "There can be no digital economy without security", with the accompanying content arguing the need for security to be a core part of any digital transformation strategy. "Security is what protects businesses, allowing them to innovate, build new products and services. Beyond a defensive role, security provides businesses with a strategic growth advantage."
Improving secure coding skills and outcomes will add a powerful layer of cyber protection for organizations, assisting them in creating better, faster code. Developers don't need to become security experts, but they must be empowered positively and practically to be the first line of defense against cyberattacks. Developers can be the next security and innovation heroes. They are very clever people, they are creative problem-solvers, and generally keen to build their skills. Play to their strengths with the specialized training they deserve, and commit to a higher software security standard. Read our white paper to find out more.
When someone wants to fly a plane, there is a very rigorous process that ensures training, practical experience, medical checks, safety knowledge and exams before they are able to fly. No-one would dare imagine that they would be let loose in the sky without this extensive preparation and validation of skills, yet this is what happens on a day-to-day basis with code writing.
There's a well-known theory that cockroaches can survive basically anything - even a nuclear explosion. While that theory only rings true to a point, their simple body composition makes them extremely hardy for their size, and difficult to eradicate under most conditions.
I've been thinking... if cockroaches had an equivalent in the digital world, it would have to be SQL injection (SQLi) vulnerabilities in code. This has been a known vulnerability for more than twenty years, yet organizations fall victim to them time and time again. The widespread, costly attack on Target was the result of SQL injection, as was an instance of election hacking in Illinois in which 200,000 voter records were exposed, prompting the FBI to recommend all IT admins work quickly to strengthen their security practices.
Imperva's Hacker Intelligence Initiative Report revealed that between 2005 and 2011, SQLi attacks were used in 83% of all reported data breaches. Today, injection vulnerabilities remain the number-one threat in the OWASP Top 10. They are relatively simple, yet they just won't die.
It seems ridiculous that this same vulnerability is still appearing in a significant number of application security scans. We know how it operates, and we know how to stop it. How is this possible? The truth is, our software security has a vast amount of room for improvement.
Veracode's State of Software Security Report - based on 400,000 application scans in 2017 " revealed an alarming statistic: just 30% of applications passed OWASP Top 10 policy. This has been a consistent theme over the past five years, with SQL injections appearing in almost 1 in 3 newly scanned applications. This is evidence of an endemic issue; we are not learning from our mistakes, and CISOs seem to face an uphill battle in being able to procure enough security talent. Typically, the ratio of AppSec specialists to developers is an inadequate 1:100.
Why is software security on life support?
It's no secret that specialist security talent is scarce, but we must also pay attention to the fact that developers are not fixing issues as they arise, and are quite clearly ill-equipped to not introduce vulnerabilities in the first place. In the same Veracode report, it was divulged that there were documented mitigations for just 14.4% of all development vulnerabilities. In other words, most vulnerabilities were submitted without development mitigation. Fewer than one-third of vulnerabilities were closed in the first 90 days, and 42% of vulnerabilities were never closed within the development period.
I speak to security professionals, CISOs and CEOs all the time, and anecdotally, I've become aware that many companies become so frustrated with the number of vulnerabilities found that can't be mitigated (in addition to the scourge known as false positives), that they stop scanning for them altogether, cross their fingers and hoping for the best.
Why do AppSec professionals let this happen?
Make no mistake: AppSec people are painfully aware of problems in code. After all, that's one of their core skills that makes them such a valuable team resource. However, they are often hamstrung by several factors.
For instance, an AppSec manager will find an issue and ask the developer, "can you fix the code?". The answer to this important question differs from organization to organization, but in general, the developer is so stretched meeting strict feature delivery sprints that they simply don't have the time to fix these problems, nor decent tools to help them. AppSec professionals themselves might be able to identify vulnerabilities, but they often don't have the skills and/or access to remediate them on the spot.
We must also realize that for every problem, there is a process of needing to find a solution, implement it, and then test it. For even the slightest issue found in the code, the time it can take to fix, not mention the resources required, is immense. There are over 700 vulnerabilities that can be introduced into software, and it's simply impossible for any one person to be able to defend against them all. It is for this reason that most companies stick to following the OWASP Top 10 only. All the while, developers keep building features and in turn, they keep introducing vulnerabilities into the code they write.
What is the solution?
The simple fact is, we don't give our developers the tools and training to foster secure coding success. There are no regulations that force organizations to ensure developers possess adequate security skills, and it's a sad reality that most universities and internships don't prepare junior developers to code securely, either.
When someone wants to fly a plane, there is a very rigorous process that ensures training, practical experience, medical checks, safety knowledge and exams before they are able to fly. No-one would dare imagine that they would be let loose in the sky without this extensive preparation and validation of skills, yet this is what happens on a day-to-day basis with code writing.
We need to spend the time to educate developers on writing secure code. However, in todays world, where software development is fast-paced as well as good developers and security professionals existing in short supply, it never seems to be a priority. It's time we changed the conversation.
A recent headline from the World Economic Forum screamed: "There can be no digital economy without security", with the accompanying content arguing the need for security to be a core part of any digital transformation strategy. "Security is what protects businesses, allowing them to innovate, build new products and services. Beyond a defensive role, security provides businesses with a strategic growth advantage."
Improving secure coding skills and outcomes will add a powerful layer of cyber protection for organizations, assisting them in creating better, faster code. Developers don't need to become security experts, but they must be empowered positively and practically to be the first line of defense against cyberattacks. Developers can be the next security and innovation heroes. They are very clever people, they are creative problem-solvers, and generally keen to build their skills. Play to their strengths with the specialized training they deserve, and commit to a higher software security standard. Read our white paper to find out more.
When someone wants to fly a plane, there is a very rigorous process that ensures training, practical experience, medical checks, safety knowledge and exams before they are able to fly. No-one would dare imagine that they would be let loose in the sky without this extensive preparation and validation of skills, yet this is what happens on a day-to-day basis with code writing.
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Click on the link below and download the PDF of this one pager.
DownloadSecure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demoMatias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
There's a well-known theory that cockroaches can survive basically anything - even a nuclear explosion. While that theory only rings true to a point, their simple body composition makes them extremely hardy for their size, and difficult to eradicate under most conditions.
I've been thinking... if cockroaches had an equivalent in the digital world, it would have to be SQL injection (SQLi) vulnerabilities in code. This has been a known vulnerability for more than twenty years, yet organizations fall victim to them time and time again. The widespread, costly attack on Target was the result of SQL injection, as was an instance of election hacking in Illinois in which 200,000 voter records were exposed, prompting the FBI to recommend all IT admins work quickly to strengthen their security practices.
Imperva's Hacker Intelligence Initiative Report revealed that between 2005 and 2011, SQLi attacks were used in 83% of all reported data breaches. Today, injection vulnerabilities remain the number-one threat in the OWASP Top 10. They are relatively simple, yet they just won't die.
It seems ridiculous that this same vulnerability is still appearing in a significant number of application security scans. We know how it operates, and we know how to stop it. How is this possible? The truth is, our software security has a vast amount of room for improvement.
Veracode's State of Software Security Report - based on 400,000 application scans in 2017 " revealed an alarming statistic: just 30% of applications passed OWASP Top 10 policy. This has been a consistent theme over the past five years, with SQL injections appearing in almost 1 in 3 newly scanned applications. This is evidence of an endemic issue; we are not learning from our mistakes, and CISOs seem to face an uphill battle in being able to procure enough security talent. Typically, the ratio of AppSec specialists to developers is an inadequate 1:100.
Why is software security on life support?
It's no secret that specialist security talent is scarce, but we must also pay attention to the fact that developers are not fixing issues as they arise, and are quite clearly ill-equipped to not introduce vulnerabilities in the first place. In the same Veracode report, it was divulged that there were documented mitigations for just 14.4% of all development vulnerabilities. In other words, most vulnerabilities were submitted without development mitigation. Fewer than one-third of vulnerabilities were closed in the first 90 days, and 42% of vulnerabilities were never closed within the development period.
I speak to security professionals, CISOs and CEOs all the time, and anecdotally, I've become aware that many companies become so frustrated with the number of vulnerabilities found that can't be mitigated (in addition to the scourge known as false positives), that they stop scanning for them altogether, cross their fingers and hoping for the best.
Why do AppSec professionals let this happen?
Make no mistake: AppSec people are painfully aware of problems in code. After all, that's one of their core skills that makes them such a valuable team resource. However, they are often hamstrung by several factors.
For instance, an AppSec manager will find an issue and ask the developer, "can you fix the code?". The answer to this important question differs from organization to organization, but in general, the developer is so stretched meeting strict feature delivery sprints that they simply don't have the time to fix these problems, nor decent tools to help them. AppSec professionals themselves might be able to identify vulnerabilities, but they often don't have the skills and/or access to remediate them on the spot.
We must also realize that for every problem, there is a process of needing to find a solution, implement it, and then test it. For even the slightest issue found in the code, the time it can take to fix, not mention the resources required, is immense. There are over 700 vulnerabilities that can be introduced into software, and it's simply impossible for any one person to be able to defend against them all. It is for this reason that most companies stick to following the OWASP Top 10 only. All the while, developers keep building features and in turn, they keep introducing vulnerabilities into the code they write.
What is the solution?
The simple fact is, we don't give our developers the tools and training to foster secure coding success. There are no regulations that force organizations to ensure developers possess adequate security skills, and it's a sad reality that most universities and internships don't prepare junior developers to code securely, either.
When someone wants to fly a plane, there is a very rigorous process that ensures training, practical experience, medical checks, safety knowledge and exams before they are able to fly. No-one would dare imagine that they would be let loose in the sky without this extensive preparation and validation of skills, yet this is what happens on a day-to-day basis with code writing.
We need to spend the time to educate developers on writing secure code. However, in todays world, where software development is fast-paced as well as good developers and security professionals existing in short supply, it never seems to be a priority. It's time we changed the conversation.
A recent headline from the World Economic Forum screamed: "There can be no digital economy without security", with the accompanying content arguing the need for security to be a core part of any digital transformation strategy. "Security is what protects businesses, allowing them to innovate, build new products and services. Beyond a defensive role, security provides businesses with a strategic growth advantage."
Improving secure coding skills and outcomes will add a powerful layer of cyber protection for organizations, assisting them in creating better, faster code. Developers don't need to become security experts, but they must be empowered positively and practically to be the first line of defense against cyberattacks. Developers can be the next security and innovation heroes. They are very clever people, they are creative problem-solvers, and generally keen to build their skills. Play to their strengths with the specialized training they deserve, and commit to a higher software security standard. Read our white paper to find out more.
When someone wants to fly a plane, there is a very rigorous process that ensures training, practical experience, medical checks, safety knowledge and exams before they are able to fly. No-one would dare imagine that they would be let loose in the sky without this extensive preparation and validation of skills, yet this is what happens on a day-to-day basis with code writing.
Table of contents
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
DigitalOcean Decreases Security Debt with Secure Code Warrior
DigitalOcean's use of Secure Code Warrior training has significantly reduced security debt, allowing teams to focus more on innovation and productivity. The improved security has strengthened their product quality and competitive edge. Looking ahead, the SCW Trust Score will help them further enhance security practices and continue driving innovation.
Resources to get you started
Deep Dive: Navigating the Critical CUPS Vulnerability in GNU-Linux Systems
Discover the latest security challenges facing Linux users as we explore recent high-severity vulnerabilities in the Common UNIX Printing System (CUPS). Learn how these issues may lead to potential Remote Code Execution (RCE) and what you can do to protect your systems.
Deep Dive: Navigating the Critical CUPS Vulnerability in GNU-Linux Systems
Discover the latest security challenges facing Linux users as we explore recent high-severity vulnerabilities in the Common UNIX Printing System (CUPS). Learn how these issues may lead to potential Remote Code Execution (RCE) and what you can do to protect your systems.
Coders Conquer Security: Share & Learn - Cross-Site Scripting (XSS)
Cross-site scripting (XSS) uses the trust of browsers and ignorance of users to steal data, take over accounts, and deface websites; it's a vulnerability that can get very ugly, very quickly. Let's take a look at how XSS works, what damage can be done, and how to prevent it.