One of the most common types of attack an application can suffer is what we call SQL injections. Since SQL injection attacks are both common and potentially devastating, it’s essential you not only are aware of them but also know how to defend your applications. That’s what this post is about: helping you protect your Java apps against SQL injections. A few other security vulnerabilities are included in the mix as well.
Cross-site scripting (XSS) is one of the most dangerous vulnerabilities in web applications. It is a client-side script injection technique that attackers can use to steal information or send malicious requests to a server. There’s no fixed way of executing an XSS attack — it all depends on how an application was built and the creativity of attackers. This makes it difficult for organizations to set up complete protection against such attacks.
Sqreen’s architecture has evolved a lot over the years. As one of the main protagonists in all these changes, I’m often asked about the previous steps we took and the rationale behind them. It’s an interesting, albeit long, conversation, so l thought I’d take a trip down memory lane and share some of the decisions we made as we built Sqreen and why. As I mentioned, it tends to be a long conversation, so I’m going to break this into three posts to make it more digestible.
When it comes to security tooling, it can be difficult to tell different acronyms and the approaches they represent apart. In the case of application security for production applications, there are several approaches out there, some new and some old. Today, I want to focus on two prevalent means of monitoring and/or protecting applications: Runtime application self-protection (RASP) and web application firewalls (WAF).
Remote code execution (RCE) is a class of software security flaws/vulnerabilities. RCE vulnerabilities will allow a malicious actor to execute any code of their choice on a remote machine over LAN, WAN, or internet. RCE belongs to the broader class of arbitrary code execution (ACE) vulnerabilities. With the internet becoming ubiquitous, though, RCE vulnerabilities’ impact grows rapidly. So, RCEs are now probably the most important kind of ACE vulnerability.
Node.js is extremely popular nowadays, primarily as a backend server for web applications. However, in the world of microservices, you can find it pretty much everywhere, playing different and important roles in a bigger application stack. One of the advantages of Node.js is the ability to install additional modules, which from the security point of view, provides more opportunities to open back doors.
GraphQL is one of the hottest topics in the API world right now. It provides an abstraction layer over more traditional HTTP communications, and has changed the way we build web applications by providing us with modern and easy-to-use tooling. As with the addition of any new technology, no matter its impact, it is important to ask whether it introduces or prevents security issues, and how to handle those.
Serverless security is a fascinating topic. As more organizations move to distributed architectures and new ways of running their services, new security considerations arise. I spoke about this topic at APIdays Paris 2020 last week, and today, I wanted to recap some of what I covered. Let’s start with the basics: what exactly is serverless, and what does it change in the ways we create software?
A SQL injection is a security attack that is as dangerous as it is ingenious. By abusing the data input mechanisms of an application, an attacker can manipulate the generated SQL query to their advantage, which can cause catastrophic events.
I recently sat down with Sr. Research Lead at Synopsys and framework specialist, Ksenia Peguero, on Episode 2 of the AppSec Builders Podcast. In the episode, “Framework Security with Ksenia Peguero: Paved Road Foundation”, we discussed how to upgrade your security through your frameworks using the Paved Road foundation. In this post, I wanted to share some learnings from that discussion.
