This series of articles will walk you through the most important topics about security and mobile applications, whatever the platform is (iOS, Android or others).
The objective is to demystify the different aspects of mobile security, in simple words.
Like many frameworks, Symfony provides built-in security. Symfony is pretty secure as a framework, but it would be a big mistake to entirely rely on that reputation to ensure the security of any application. Because every application is different, the security context is different. Therefore, developers still have a big role in ensuring everything is properly configured and tested.
Input filtering, authentication and session management… This series of articles will go through the different mechanisms that you, as a Symfony developer, can use to make sure the application you develop is safe and reliable.
And because built-in security does not necessarily mean “already done”, we will see what is really important and common pitfalls.
Do you usually conduct application testing before releasing? In this article you will find out why conducting outsourced penetration testing can strongly strengthen your application security level and your brand image.
Updated: 23 Dec. 2020
This article does not replace a good knowledge of security principles in PHP, but can give you some good advices that really boost security.
There will be nothing to copy/paste straight forward to your PHP files. But we believe that these tips and best practices will bring you long-term benefits if you understand and implement the different points according to your needs and context.
This article is the third of our series dedicated to PHP security. The first article gives you guidelines for PHP configuration, updates, data filtering and sanitization, as well as code organization.
The second article discusses protections against known and common attacks.
We will now take a look at file uploads, CRSF, cookies and security through obscurity.
Updated: 23 Dec. 2020
This article does not replace a good knowledge of security principles in PHP, but can give you some good advices that really boost security.
There will be nothing to copy/paste straight forward to your PHP files. But we believe that these tips and best practices will bring you long-term benefits if you understand and implement the different points according to your needs and context.
This article is the second of our series dedicated to PHP security. The first article “How to Protect Your Website: PHP Security Tips and Tricks #1” gives you basic guidelines for PHP configuration, updates, data filtering and sanitization, as well as code organization.
We will now look at common hacking attacks against PHP websites and how to defend yourself against them.
Updated: 1 Dec. 2020
PHP remains the most popular server-side programming language: it is used by almost 80% of websites (source). This language continues to be developed, and PHP 8 was released last week ! This version brings new features and should enhance security.
However, the security of PHP builds up from its ‘historical’ core features. The following article does not replace a good knowledge of PHP, and there will be nothing to copy/paste directly into your files. But we believe that these tips and best practices will bring you long-term benefits if you understand and implement the different points according to your needs and context.
Today we cover PHP configuration, updates, code organisation and data filtering/escaping.
Updated: 16 Feb. 2021
Business logic flaws remain a type of little-known vulnerability in IT-Security. They are not errors in the logical reasoning, but flaws related to the working of a web application. They are different from technical vulnerabilities, which directly relate to code, implementation or configuration errors.
We regularly find logic flaws during penetration tests, on all types of applications. We find them most frequently on e-commerce sites and SaaS software.
What is 2FA
Two Factor Authentication (2FA) is a way to strengthen users authentication.
A good example is when you want to trigger a bank transfer from your bank website: depending on your bank, you may receive a text message on your mobile phone, containing a code that you must put back on the website to confirm the transfer.
The second factor can be a phone, a physical object in your possession, some physical characteristic (biometrics) or a secret that only you know.
A 2FA process comes with some disadvantages: it makes the authentication process more complex, and the second factor has to be “available”, which can be a problem with a mobile. Flat battery, bad network coverage or any other hazard can prevent the process from working properly.
The need for web application firewalls
If you don’t perfectly see the difference between a firewall and a web application firewall, I recommend you read this article we published a few weeks ago, explaining the differences: Traditional Firewalls or Web Application Firewalls?
The reality of threats makes web application firewalls a real complementary approach to secure coding practices and security testing.
Global protection against known (and unknown) attacks, virtual patching and security events reporting are real added values.
Traditional firewalls protect IT environments against external attacks, by allowing and blocking connections to certain areas.
These firewalls control incoming and outgoing network traffic, based on a set of rules.
Here is a basic example:
Let’s suppose your company has a web server inside its infrastructure. In order for the web server to be reachable from outside your company, some rules will have to be established to authorize web traffic to and from that server.
Some “ports” will be open, on a given IP address (the one of your server).
Your company can choose to allow web traffic only, or allow other traffic according to its needs.
Sometimes security can represent a heavy investment in terms of web development.
But there are some tiny adjustments that you can implement on your website that will help you making substantial progress in security. In fact these adjustments are really small in terms of code and configuration, but have a significant impact that requires proper analysis and validation before being implemented.
Here is how HTTP headers can help you in your security efforts.
Better than just rewriting technical specifications and explaining all the details of these HTTP headers, we will focus on giving you a synthetic analysis and a list of interesting links you would like to browse if you need further details.
One important thing to keep in mind is that these headers have an impact on the browser side. They control how web browsers must behave (if they implement the corresponding functionalities). They do not modify the server’s behavior.
Some years ago this was a common question: should I conduct a pentest on my website? Today the real question is: how often should I conduct a pentest? This does not only apply to websites but more generally to all applications and software developed with web technologies. Although systems and servers also need security, in this article we will only focus on the application layer, which usually faces a lack of awareness regarding to its breaches.
Web Application Firewalls (commonly referred to as WAF) are mainly designed to protect web applications.
But what exact roles can they play in a web architecture?
Depending on how they are integrated in your web platform, their impact and ability to improve your security will differ.
Using a WAF as an attack mitigation solution
A WAF can be used to analyse inbound and outbound traffic in order to block malicious or dangerous items.
In this configuration, the threat detection engine of the firewall detects suspicious inbound traffic and decides to block the request. This means that the request will not reach the web server, and a generic response will be returned to the client.
To decide whether a request is innocuous or malicious, the WAF can use a positive or a negative security model:
The negative security model assumes that all transactions are innocuous, by default. It will look for threat cues and if judged dangerous, block the transaction.
The positive security model, on the other hand, assumes that all transactions can be dangerous and only allows those that are recognized as safe.
