Security

Web Application Firewall (WAF) – l’etat de l’art (1)

Adrian Citu

Introduction

Au cours des dernières années, une tendance claire se dégage au sein du paysage de la sécurité de l’information; les applications Web sont l’objet d’attaques.

Les applications Web continuent d’être un des principaux vecteurs d’attaque
pour les criminels, et la tendance ne montre aucun signe de ralentissement.

En effet, de plus en plus, les pirates évitent les attaques réseau au profit d’attaques par cross-site scripting (XSS), d’injections SQL et de nombreuses autres techniques d’infiltration destinées à frapper plus haut dans le modèle OSI, au niveau de la couche applicative en général, et du Web en particulier.

Aujourd’hui la plus part d’architectures réseaux sont protégées contre des attaques venant de l’extérieur par des firewalls classiques. Mais dans le plus part des cas, les ports http/https ne sont pas du tout protégées ou filtrées. C’est dans ce contexte que les pare-feu applicatifs web (WAF) on vus le jours.

Un pare-feu applicatif Web (WAF) est une application ou une appliance
qui surveille les conversations entre un navigateur client et un serveur web au niveau des packages http. Le WAF a la possibilité d’appliquer des politiques de sécurité fondées sur une variété de critères, y compris des signatures d’attaques connues.

Le pare-feu applicatif Web est donc destiné à prévenir les attaques là où les pare-feu réseau et les systèmes de détection ou de prévention des intrusions cessent d’être efficaces. A noter aussi qu’une mise à jour de la norme PCI DSS (Payment Card Industry Data Security Standard), effective depuis juin 2008, exige de sécuriser les applications Web via l’analyse du code ou des firewalls WAF.

(Quelques) Types d’attaques contre les applications web

Déni de service

La méthode est d’utiliser un réseau de bots pour générer un flux de requêtes vers une application. L’exemple le plus simple est d’envoyer simultanément des milliers de requêtes sur la page d’accueille d’un site public pour rendre hors service le serveur web.

En fonction du type d’application, une requête sur une page dynamique génère sur le serveur et la sur la chaine applicative (serveur d’application et base de données) une charge conséquente (génération des requetés SQL, appel a d’autres instances d’applications telle qu’un service web). Lancer le traitement de cette chaine plusieurs milliers de fois par seconde est en général fatal, le composant le plus faible cédant en premier, en rendant alors l’application indisponible.

Élévation des privilèges

Pour mener cette attaque, il faut que l’attaquant soit déjà connecté sur l’application avec un compte utilisateur. Avec ce compte, il part à la découverte de l’application et tente d’accéder a des fichiers de configuration ou de mot de passe. Par exemple les répertoires suivantes peuvent être accèdes pour tenter d’y découvrir des fichiers de configuration, comptes administrateurs : « /system/ » ; « /passwords/ » ; « /logs/ » ; « /admin/ ».

Injection de code

Une injection de code se produit quand un utilisateur envoie du code au serveur et l’oblige de l’exécuter. Les attaques le plus connus par l’injection du code sont l’injection du SQL et l’injection du PHP.

Une attaque par injection SQL se compose d’insertion d’une requête SQL dans les données  envoyées par le client au serveur. Une attaque réussi  peut lire les données sensibles à partir de la base de données, modifier les données de base de données (INSERT / UPDATE / DELETE), exécuter des opérations d’administration sur la base de données (telles que l’arrêt du SGBD), récupérer le contenu d’un fichier présent sur le système de fichiers de la base de données et dans certains cas d’emmètre des commandes au système d’exploitation.

L’injection PHP est similaire à l’injection SQL mais on remplace le code SQL par du code PHP.

Cross-Site Scripting (XSS)

Une application web est vulnérable aux attaques de type XSS quand un attaquant peut forcer l’application de lui retourner des données soumises non altérées. Ce mécanisme lui permet d’insérer des chaines de caractères spéciales dans la page HTML retournée par le serveur.

Un exemple d’une chaine de caractères spéciale est : <script>alert(« XSS« ) ;</script> qui auras comme résultat l’affichage d’une fenêtre dans le navigateur.

Vol de session HTTP

Un utilisateur d’une application web a le control complet sur la réponse qu’il envoie au serveur. Cette affirmation est spécialement vrais pour les éléments qui stockent de l’information d’état d’une page web comme les cookies http, les champs http cachés, les entêtes http et tous les éléments http  qui peuvent être contenus dans un formulaire http.

Le protocole http est un protocole « sans états » : rien ne permet de lier entre elles les requetés provenant d’un même utilisateur. Les applications utilisent massivement les cookies pour palier ce problème. Les cookies présentent deux vulnérabilités :

  • Les cookies sont facilement manipulable à l’aide d’outils comme Fiddler ou Tamper Data. En envoyant des valeurs de cookies « au hasard » ou en utilisant des algorithmes de génération de cookies connus, il est possible de se faire passer par un autre utilisateur.
  • Les cookies peuvent être volées et réutilisés. On parle d’attaques par vol de session. Sur un réseau local, un simple « sniffer » suffit pour capturer un cookie. Sur Internet, cette attaque est plus complexe, mais les attaques de type XSS permettent de récupérer des cookies. Ces cookies peuvent être ensuite réutilisées pour qu’un attaquant se fasse passer pour un utilisateur légitime.

Book review: Foundations of Security (Part 3 Introduction to Cryptography)

Adrian Citu

Chapter 12:  Symmetric Key Cryptography

The chapter starts with an introduction to cryptography that consists in explaining some notations and terminology. Then the block ciphers are explained and the following algorithms are introduced:

The second part of the chapter introduce the stream cyphers and as examples the One Time Pad and RC4.

Chapter 13: Asymmetric Key Cryptography

This chapter explains how the asymmetric key cryptography algorithms are working and briefly explains the RSA and Elliptic Curve Cryptography (ECC) algorithms; it also highlights one of the most important problem of the asymmetric key algorithms which is the public key creation and exchange.

Chapter 14: Key Management and Exchange

Key management refers to the process by which keys are generated, stored, agreed upon and revoked. The chapter is structured on 3 parts:

  • Key generation (how should new keys be created). For the key generation the authors focus on securely generating random numbers by using the C rand() function, using the Random APIs (CryptGenKey library or java.security API) or random device files.
  • Key Storage (how should keys be securely stored so that they cannot be easily stolen). The authors propose some solutions and starts from non secure storage “platforms” (as storing the keys into the compiled code or to a disk) until more secure “platforms” as external devices like smart cards, Hardware Security Modules (HSM).
  • Key agreement and exchange (how should to or more parties decide on a session key used to protect the confidentiality of their conversation). The authors present two ways that can be used to initiate a conversation:
    • generate a cryptographically random conversation key and  encrypt it with a public key
    • use Diffie-Hellman key exchange protocol

Chapter 15: MACs and Signature

This chapter presents Message Authentication Codes (MACs) and digital signatures. A MAC is  sequence of bits that can be attached to a message to verify where is originated and that is has not been tampered with. For MACs construction the authors present the following algorithms CBC-MAC and HMAC.

Chapter 16: Exercises for Part 3

As usually this chapter contains some questions and problems in order to test the comprehension of the notions discussed in the chapters 12-15.

(My) Conclusion

For me the book fulfill his goal: to present in a (rather) clear and concise way the fundamental notions about the security but what I disliked to this book is the writing style which I find it rather difficult to follow sometimes.

Book review: Foundations of Security (Part 2 Secure Programming Techniques)

Adrian Citu

Chapter 5: Worms and other malware

This chapter present some “famous” worms that had major impact on the security industry.  Every worm presented in the chapter had used one of the security holes that will be presented in the following chapters: Morris worm (buffer overflow of the finger daemon server), the Code Red worm ( buffer overflow of the II Server), the Nimda Worm (buffer overflow of the II Server and infection using the web browser), the Blaster worm (buffer overflow of the DCOM), the SQL Slammer (buffer overflow of the SQL Server).  The authors also presents definitions of another types of malware like rootkits, botnets, spywares, keyloggers, adware, trojan horses, clickbots.

Chapter 6: Buffer Overflows

This chapter threats the buffer overflow vulnerabilities; a very small example (written en C) is presented and explained then the possible solutions to this problem are enumerated and explained :

The end of the chapter presents another types of memory corruption vulnerabilities:

Chapter 7: (Web)Client-State Manipulation

The goal of this chapter is to present how a malicious user can pass to a web server modified requests. The example used as example is a pizza ordering web site which accepts GET requests containing sensitive information as the price of pizzas or the number of bought pizzas.  The attack scenario consists in modifying the values of the parameters sent to the server (ex: by 10000 pizzas at the price of 0 $).  The possible solutions to this kind of attack would be :

  • sensitive information stays on the server. Don’t send sensitive information to the client, send only an id (session id) identifying the client sensitive informations. Another technique is to send to the client a signature of the session in order to prevent the tampering of the session if by a (malicious) client.
  • do not use HTTP GET but use HTTP POST. The HTTP POST use can be combined with the use of cookies and or use of JavaScript.

The main idea of this chapter is  web application should never trust the clients and should always validate the clients input.

Chapter 8: SQL Injection

Using the same example as in the previous chapter (the pizza ordering web site) the authors explains the anatomy of a SQL injections attack and then they propose various solutions to this kind of attacks. The proposed solutions are:

Chapter 9: Password Security

This chapter goal is to present some of the techniques used by a password management system in order to reduce the impact of an attack. The authors will prove some of these techniques by implementing a mini-password manager that can be plugged-in into the toy web server (presented in Chapter2 :Secure Systems Design) for authenticate the users . The mini-password manager implementation starts by a straw man proposal, the users and passwords are stored into a property file. The following state is to replace the passwords by hashed versions. In order to mitigate the dictionary attacks a “salt” is added at every password. At the end of the chapter, the authors briefly presents additional security techniques :

  • password filtering (if a user choose a password that is in the dictionary or identified as easy to guess then must require to the user to choose another one).
  • limited logging attempts (the user have a limited number of login attempts before the account is locked or disabled)
  • aging passwords (the users are forced to change the passwords after a certain time)
  • one time passwords

Chapter 10: Cross-domain Security in Web Applications

This chapter starts by explaining some concepts linked to the web application security; same policy origin, Http Request Authentication, lifetime of the cached cookies and the the HTTP Authentication credentials. Then, some attack patterns are presented in detail:

The last part of the chapter presents the solutions for preventing each of the attack patterns.

The proposed solutions for the XSRF are:

  • inspecting the Http referrer headers (not a complete solution since the Http headers can be modified on the fly )
  • validation of the Http user forms via a user-provided secret (every Html form contains an additional field representing the user password; not very user friendly)
  • validation of the Http forms using an Action Token (in order to distinguish “genuine” instances of forms from ones that were forged by a third party, a token is included as a hidden field in the form. The main difficulty is to find a generation schema in order to be impossible for a third party site to generate valid tokens)

Solutions for preventing the XSSI are:

  • use an Acton Token (s in the case of XSRF)
  • restrictions to form submission only using Http POST

Solutions for preventing XSS are :

  • HTML escaping (any string that is possibly derived from untrusted data and is inserted into an HTML document must be HTML-escaped).
  • HTML tag attributes (form fields attributes, URL attributes, JavaScript-valued attributes) must be quoted.
  • use of HTTP-only cookies (cookies that will no be exposed to client-side scripting)
  • bind Session cookies to IP address

Chapter 11: Exercises to part 2

As for the first part, this chapter contains questions and exercises in order to “walking the walk not just talking the talk”.

Book review: Foundations of Security (Part 1 Security Design Principles)

Adrian Citu

Lately, I was interested on “security applications” (view Security certifications for programmers) so I will do the review of the Foundations of Security: What Every Programmer Needs to Know.

Chapter 1:  Security goals

The first chapter make a brief description of the security domains. For the author the IT security can be split on the following domains:

  • Physical security (mechanisms that limit the physical access to the IT material: locked doors, card readers, biometric lockers, etc… )
  • Technological security
    • Application security (the domain that this book covers)
    • OS security
    • Network security
  • Policies and Procedures (each employee may need to be educated to never give out her password, the systems are so that the system administrators have the ability to reset passwords)

The chapter also introduce and explains the seven key concepts in the security field :

  1. Authentication (is the act of verifying someone identity)
  2. Authorization (is the act of checking whether a user has permission to conduct some action)
  3. Confidentiality (is the act of keeping the content of a transient communication or data accessible only to authorized entities)
  4. Message/Data integrity
  5. Accountability (the goal of the accountability is to ensure that you are able to determine who is the attacker in the case that something goes wrong)
  6. Availability (an available system is one that can respond to it’s users in a reasonable timeframe)
  7. Non-repudiation (is the act of ensuring the undeniability of a transaction by any of the parties involved)

Chapter 2: Secure Systems Design

The chapter contains some general advices in order to design secure systems. The fist advice is that it must understand the threats that can impact your project/organization. The author enumerate some of the possible security threads that can occur if the security is not part of the product design: web site defacement, computer infiltration (using buffer overflow, command injection, etc), phishing, pharming (dns cache poisoning), click fraud, denial-of-service.
In order to present various security design problems, the authors presents the code of a simple web server (you can find teh code here); the web server  is written in Java language and a complete code walk through is made in the chapter.

I must admit that was very hard to extract the essence (the main ideas ) of this chapter, for me the style is very unclear and I simply think that a part of this chapter would had a better place into the next chapter (Secure Design Principles).

Chapter 3: Secure Design Principles

In this chapter the authors enumerate and explain various principles in order to create a secure system. The following principles are explained:

  • the principle of least privilege (a computer or a user should have the minimum amount of privileges for accomplish a task)
  • defense in depth (the defense of a system must reside on multiple security layers not a single layer)
  • diversity in defense (use multiple heterogeneous systems that do the same thing, ex: use different operating systems in you infrastructure)
  • secure the weakest link (the system is only strong as the weakest link)
  • fail-safe stance or failing securely (design a system in such way that even if one or more components fail, the system can still ensure some level of security).  In order to explain this principle, the authors will use the web server from the previous chapter.
  • secure by default (when designing a system, by default should be optimized for security wherever possible)
  • simplicity (keep the software as simple as possible to preserve the software security)
  • usability (in order to be usable, a software product should let the users to accomplish the tasks that the software is mean in most securely way). It is true that the usability and the security are sometimes 2 antagonist properties.

Chapter 4: Exercises for Part 1

The chapter contains some exercises linked to the previous chapters. Some of the exercises are just questions about things explained in the previous chapters, others are programming exercises (mount an attack to the web server or implement a  basic HTTP authentication).

Security certifications for programmers

Adrian Citu

This blog entry starts from a very simple question : “What a programmer need to know about the security in order to write more secure code ?” I know that IT security is a very vast topic but in my case I’m interested only in “application security”.  My goal was to find some certifications that will teach me the basics of the “applications security”. You may wonder why I chose to look for the certifications, why not “normal” trainings.  I choose to look for the certifications because I supposed and hoped that will provide me an objective measure of knowledge, skills and abilities.

So here are the security certifications for programmers:

What I like about these certifications is that it gives you all the necessary informations before passing the exams but on the other side I was not convinced about the  previews offered on the site.

What I like about GSSP is that are different exams for different languages since the security risks are not the same for all the programming languages. What I don’t like (beside the price) is the missing of a study guide.

  • Certified Secure Software Lifecycle Professional(CSSLP) The process of certification is quite difficult: must provide proof of four years in the Systems Development Life Cycle (SDLC) process or 3 years plus a bachelors degree or regional equivalent in an IT discipline, submit Experience Assessment essays or pass examination, complete the endorsement process. The certification is focused on security of the following SDLCs: Systems Development Life Cycle, Secure Software Requirements, Secure Software Design, Secure Software Implementation, Secure Software Testing, Software Acceptance, Software Deployment. The price of the exam is $650 USD and the recertification is required every three years under the following conditions : earn 90 Continuing Professional Education (CPE) credits (minimum 15 CPEs earned each year) and pay annual maintenance fees ($100 USD). In case you need a study guide you can take a look at this book The CSSLP Prep Guide: Mastering the Certified Secure Software Lifecycle Professional (not released yet).
  • EC-Council Certified Secure Programmer (ECSP) In order to be an ECSP you must pass an exam ($250). Associated training is available  (online training). On the site EC-Council offer very often free courses consisting in only one day. If you do not take the associated training from the EC-Council, you must complete an eligibility form before you can take the exam and for recertification each member must achieve 120 credits within 3 years and clock in 20 credits per year.
  • EC-Council Certified Secure Application Developer (CSAD) The CSAD is a ECSP + application development certification (for Linux: LCE / LCA / RHCE / LPI certification, for Microsoft: MCAD / MCSD / MCTS / MCPD certification, for Sun:  SCJD / SCEA certification, for Oracle: OCP certification ( DBA), for IBM: Websphere certification)