Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Securing applications is not the easiest thing to do. An application has many components: server-side logic, client-side logic, data storage, data transportation, API, and more. With all these components to secure, building a secure application can seem really daunting.
Thankfully, most real-life vulnerabilities share the same root causes. And by studying these common vulnerability types, why they happen, and how to spot them, you can learn to prevent them and secure your application.
It looks like IT teams have no respite. Following all the hassles caused by Log4j (and its variants), there is a new high profile, high-risk vulnerability making the rounds. CVE-2021-4034, or PwnKit if you’re into fancy CVE nicknames, is a polkit vulnerability that lets unprivileged users gain root privileges on basically any Linux system out there that has polkit installed.
NOTE: Patches are now available for Centos6, Oracle6, CL6, Ubuntu16, and Centos8.4 with more to follow. You can track actual distribution support through a CVE dashboard here.
If you’re an SRE, you’ve almost certainly heard all about Log4Shell, the Log4j vulnerability that some analysts are calling the worst software security flaw in decades. And you’ve also hopefully by now patched any systems you manage to fix the vulnerability (if you haven’t, go do that right away!).
Even after you’ve patched Log4Shell in your environments, though, you shouldn’t put the vulnerability in the back of your mind. For SREs, there are some important lessons to glean from this fiasco.
Is the MariaDB Java connector affected by the security vulnerability recently discovered in Log4? By default, the Java connector does not use Log4j. However, if you have configured it to use SLF4j, keep reading.
For information beyond the scope of the MariaDB JDBC driver, read Log4Shell and MariaDB.
We continue to develop PVS-Studio as a SAST solution. Thus, one of our major goals is expanding OWASP coverage. You might ask, what's the use when there's no taint analysis? That's exactly what we thought - and decided to implement taint analysis in the C# analyzer. Curious about what we accomplished? Read on!
Note. This article briefly touches upon the topics of SQL injections and working with SQL in C#. This theory serves as context. For in-depth information on these topics, do additional research.
Software security is a critical topic that has been the focus of attention of many researchers and professionals over the years. One of the reasons this subject does not lose relevance is the number of vulnerabilities that become known each day. According to NVD (2006), a vulnerability can be defined as "a weakness in the computational logic (e.g., code) found in software and hardware components that, when exploited, results in a negative impact on confidentiality, integrity, or availability". The numbers surrounding this type of computational issue give a more concrete panorama about its criticality. Seacord (2013) states that in a period of nine years — from 2004 to 2012 — a total of 45,135 vulnerabilities were reported and cataloged by the National Vulnerabilities Database — NVD — of the National Institute of Standards and Technology — NIST. Yet, only in the year 2019, the NVD received 18,938 new entries.
In terms of secure programming, two categories of vulnerabilities have been exploited by attackers so that to damage the correct running flow of a software. The first one is String-related vulnerabilities. Basically, failures of this category cause a kind of security threat known as buffer overflow. Another widespread category of vulnerabilities is Integer-related. The most common errors found out in this category are overflow and signed errors. All those situations can lead to unexpected behaviors and the system can end up in an unsecured state. In scenarios like those ones, mitigation strategies turned to avoid jeopardizing a program or even a whole system generally are based on a solid knowledge of the employed programming language and in an accurate manner to explore its resources.
With data breaches on the rise, creating and maintaining secure software is vital to every organization. Although not all attacks can be anticipated or prevented, many can be avoided by eliminating vulnerabilities in software. In this article, you’ll learn about some of the most common software vulnerabilities and how to avoid these issues. You’ll also learn some general best practices for ensuring that your software and data remain secure.
The vulnerabilities below are just a few of those identified in MITRE’s 2019 CWE Top 25 Most Dangerous Software Errors list. Many of these issues continue to be included in software despite being widely known and used by attackers.
Awhile back, I had a conversation with a friend that I went to school with (currently a senior member of the engineering team at a large retail chain) who was tasked with the job of identifying potential application security partners (he addressed vendors as partners, which I personally liked) that they could collaborate with on various areas as part of their product security initiative. The following piece emerged as an extension of my immediate thoughts when he shared his views of what could have made his experience of interacting with front line sales and marketing folks better.
In the context of DevSecOps, much has been said about the need for engineering to speak security, security to speak code, DevOps to speak security, etc. But, as a Technology Service Provider (TSP), riding the current wave of application security, its almost mandatory for the Sales and Marketing teams to speak relevant tech!
You may also enjoy: Integrating Docker Solutions Into Your CI/CD Pipeline
Nancy is now wrapped up as a Docker image for execution in a pipeline or via an alias in a terminal.
Nancy is a tool to check for vulnerabilities in your Golang dependencies, powered by Sonatype OSS Index. docker-nancy wraps the nancy executable in a Docker image.
A popular development environment, Ruby on Rails features a simple syntax. The environment is accommodating by nature, allowing teams of varying sizes to work in complete harmony. Developers find it fairly easy to learn, and thus, it is one of the most popular development technology available today.
Thanks to Apple, the web development framework saw an overnight upsurge in its popularity. However, in 2012, security breaches invited massive criticism from its patrons.
Chances are, while you’re reading this, there are frantic boardroom meetings happening in some parts of the world. Imagine CxO’s shivering to their bones, urging their IT security teams to "do something" about the web application security breach they’ve been hit by. That’s how web application security breaches are.
You may also like Why Framework Choice Matters in Web Application Security.
What do the numbers say?
If JavaScript is your programming language of choice, you probably don't have to worry about string concatenation all that much. Instead, one of the recurring problems you might encounter is having to wait for JavaScript's npm package manager to install all of the required dependencies. If that sounds all too familiar, and you have some time on your hands until npm is done, you might as well spend it reading about how string concatenation works in other languages.
In this blog post, we examine why string concatenation is a complicated topic, why you can't concatenate two values of a different type in low-level programming languages without conversion, and how string concatenation can lead to vulnerabilities. We'll also explain how format strings that contain placeholders for certain types of data can cause serious trouble if they are controlled by an attacker. And, we'll conclude with a simple way to fix them.
While some organizations and executives may not be fully aware of all the threats to their mobile applications, the risks are real and growing. Vulnerabilities arise from code flaws, encryption errors, unsecured data transmission or data exposure. Attackers are ready to exploit these vulnerabilities to steal data, money and trade secrets and undermine your brand.
Reflecting on some recent high-profile mobile application security breaches helps drive home the dangers of not properly securing your mobile apps. With that in mind, we present a round-up of the top five mobile breaches that have occurred over the past year.
Snyk recently released its annual State of Open-Source Security Report for 2019, which highlights the current landscape of open-source security, as a whole, and clearly illustrates that vulnerabilities in container images are no exception.
The report showed results from data collected in a recent survey of more than 500 open-source developers and maintainers, data from public application registries, library datasets, GitHub repositories, and Snyk’s comprehensive vulnerability database continuously pulling in data from hundreds of thousands of projects monitored and protected by Snyk.
This past weekend, as I was catching up on my reading, an older article caught my attention. It talked about how credit card numbers remain one of the top 10 types of stolen data traded on the dark web. It’s mind-boggling to learn how much you can earn from these stolen credit card numbers. Prices range from $5 to $110, with CVV data adding $5 and full bank info $15. A full package with name, social security number, birth date, and other personal data can cost another $30!
The tremendous value of this information, coupled with improper handling of sensitive data, is one reason for the high frequency of data breaches. Data breaches are a pervasive problem that affects multiple industries and organizations that handle or store personal information.
Due to its agile, flexible, and cost-efficient services, cloud solutions are inevitable for business operations and so are the unavoidable security risks and the probability of malicious attacks that you might have to endure. Cloud security threats are plenty. CSA’s nefarious twelves have listed and positioned Cloud API and insecure interfaces in the number three among the other persistent risk factors that are associated with cloud computing and the OWASP Top Ten report also acknowledged it as a primary security concern that demands intensive risk mitigation efforts.
A Cloud Application Programming Interface (Cloud API) is what facilitates the cloud services by enabling the development of applications and services provisioning the cloud hardware, software, and platforms. Cloud API is a gateway that provides access to the direct and indirect cloud infrastructures and software as the services. Cloud APIs are the means to interact with the cloud infrastructure to designate the computing, storage, and network resources for the concerned cloud applications or services. A key element in provisioning the cloud services cloud APIs are primarily based on the REST and SOAP frameworks. Along with cross-platform and cloud providers' APIs, there are also open APIs and vendor-specific APIs that helps to control the cloud resources and their distribution.
Original article published by Cristián Rojas at Hackmetrix Blog
The EQUIFAX USA event of 2017 put a spotlight an under-considered aspect of software security: it’s not just our code that we need to secure. The facts of the case are widely known, but its cause? Not so much. Little is said about the fact that this leak would not have taken place if the developers of the EQUIFAX application had upgraded their Apache Struts web framework to a more secure version.
The linking concept of today's article differs from usual. This time it is not one project, the source code of which was analyzed, but a number of warnings related to one and the same diagnostic rule in several projects. What's interesting about this? The point is that some of the considered code fragments contain errors reproduced when working with the application and other fragments even represent vulnerabilities (CVE). In addition, at the end of the article, you will find a small talk on security defects.
All errors we will look at in this article have a similar pattern: