Wednesday, October 29, 2014

Terugblik op de Atos Cyber Security Event - Cyber Survival (Dutch)


Op 29 oktober 2014 heb ik gesproken op het Atos Cyber Security Event (symposium) waarvan het thema dit jaar Cyber Survival was. Het dagdeel werd gevuld met onderwerpen die technisch van aard, maar ook procesmatig/organisatorisch van aard waren. Alle presentaties kunnen onderaan deze blogpost gevonden worden.

Dit event is ook door ALERT Online onder de aandacht gebracht. Alert Online is een gezamenlijk initiatief van overheid, bedrijfsleven en wetenschap en helpt om de kennis over online veiligheid te vergroten. Voor jong en oud en van werkvloer tot boardroom. Met duidelijke en praktische tips en trucs over hoe we veilig online kunnen zijn.

De sprekers

De dagvoorzitter was Abbas Shahim. Hij begeleide op een vrolijke, maar zeker ook professionele wijze de dag. Het event werd formeel geopend door Johan van Campen, Directeur Managed Services van Atos Benelux & The Nordics (BTN). Hij vertelde over de ambities van Atos met betrekking tot security en op welke wijze Atos met security om wil gaan. Dit in samenwerking met Bull.


De eerste spreker van de dag was Frans van Leuven, Atos Product Manager Security services. Hij sprak over het onderwerp DDOS Mitigation Services. Hierbij werden onderwerpen als Advanced Persistent Threats behandeld, maar ook welke middelen, zoals DDOS Mitigation Services, ingezet kunnen worden om deze dreigingen te mitigeren.

De tweede spreker was Sylvia Bunte, Atos Solution Architect Informatiebeveiliging. Zij sprak over de toegevoegde waarde van Intrusion Prevention/Detection Systems. Stap voor stap werd er toegelicht hoe de grote voorraad aan alerts gereduceerd kan worden en wat het effect hiervan is op de uitvoering van de analyses van de alerts.

De derde spreker was ik zelf (Joram Teusink), IT Security Officer RCX. Ik sprak over het AOCG Security Threat Model. Een model waarmee structuur gegeven kan worden aan de dialoog tussen de business en de security professional. Dit wordt gedaan door middel van het inzichtelijk maken van de samenhang tussen de actor, onzekere gebeurtenis, dreiging en de beheersingsmaatregelen van de wereld van informatiebeveiliging. Deze samenhang is op een toegankelijke wijze voor de business beschreven, maar ook hanteerbaar voor de security professional.

De vierde spreker van de dag was Andor Buding, Atos Solution Manager Security. die ons wat kwam vertellen over de toekomst van Quantum Encryptie. Ondanks de complexiteit van de (nog in ontwikkeling zijnde) technologie wist hij op een toegankelijke wijze de materie over dit onderwerp over te brengen.

De een na laatste spreker was Sander Dortland, GasTerra B.V. Security Officer. Hij vertelde over de wijze waarop GasTerra met haar security omgaat en welke middelen hij inzet om de juiste security in te richten en te onderhouden bij zijn organisatie. Dit wordt onder andere gedaan aan de hand van de ISO 27002 norm.

De laatste spreker van de dag was Regien Schagen, Atos Executive Business Consultant GRC. Zij gaf een duidelijke uiteenzetting over, inclusief voorbeeld, de onderwerpen Governance, Risk & Compliance. Aan de hand van enkele modellen en een handige tool liet ze zien hoe enerzijds de awareness in een organisatie vergroot kan worden en tegelijkertijd een goede risico assessment verkregen kan worden.

Het was een leuke en leerzame dag en dit event was extra bijzonder voor mij zelf. Dit was namelijk het eerste event waarbij ik als officiële spreker een onderwerp mocht presenteren. Mijn dank aan Atos voor het bieden van een platform waarbij ik dit kon doen en ervaren!

Info Security 2014

Na afloop van het Atos Cyber Security event zijn mijn collega, en mijn backup-spreker van het Atos event, Rick Veenstra naar de InfoSecurity vakbeurs in Utrecht gegaan (op beide dagen overigens). We zijn die woensdag ook nog even op de foto gezet terwijl we naar het grote plattegrond van de beurs aan het kijken waren.


Saturday, October 11, 2014

Input validation for web-applications, how to process input safely and securely - Part 3 of 3

This is part 3 of 3 of the blog series about input validation for web-applications. In the first part the entire process was explained. In the second part we did some coding on the client-side, and now we will look in to server-side coding in PHP. But keep in mind that the same principles apply to all programming languages.

Input validation is not only about security. It is also about building user-friendly applications (a message when the data-entry does not comply) and keeping data consistency (all data is stored in the same format). In example, you can choose to store all dates in yyyy-mm-dd format in your database. When you make sure you do that, you can easily analyze and generate statistics of the data in your database. When a user of the system enters data in a wrong format, you can either automatically change it (sanitization), or send a message to the user to enter it in the correct format.

Part 1 - Input validation process
Part 2 - Input validation coding client-side
Part 3 - Input validation coding server-side

The input requirements

In the previous post we used the example of requirements below. This example came in the form of a a small register form with the most basic input values. The following input is requested from the user, including all the requirements of the input data and in this stage it is sent to the web server.
  • Name (name and surname)
    • Required
    • Maximum length is 50 characters
  • E-mail address
    • Required field
    • Needs to validate as email address
  • Password
    • Required field
    • Requires at least one lower and one uppercase letter, one digit, no spaces and a length of 8-16 length
    • Must be same as repeat password
  • Repeat password
    • Required field
    • Requires at least one lower and one uppercase letter, one digit, no spaces and a length of 8-16 length
    • Must be same as password
  • Birthdate
    • Optional
    • Needs to validate as a proper date (mm/dd/yyyy)
  • Personal website
    • Optional
    • Must validate as a proper url
    • Only http and https is allowed
Very basic values of course, but good enough for the example throughout the client-side and server-side input validation coding. It is very important to first sit down with your co-workers about the requirements of the data, before actually start coding.

Input validation Steps

For every step in the process we will look at what it might mean for Javascript. Some steps will not be required at all, some optional and some definitely required.
  1. Check if the input is actually sent and received
  2. Store input in memory, separate it from the source
  3. Check variable for, and remove all scripting
  4. Trim the variable
  5. Truncate the variable to the maximum size of expected value
  6. Check if it is the correct variable type and / or format
  7. Check if it is expected content (also called white listing)
  8. When relevant, check existence of local resources
  9. And now is it input for the process

Server-sided PHP

The server-sided code for input validation can be found below. In this situation we use PHP and I will show two kinds of examples. One is the input validation only and the other is input validation and sanitization. Keep in mind with sanitization that when done on the server-side, you probably need it also on the client-side (there is no point doing server-side only, as the user will face input validation errors by the client-side validation).

That being said, all steps are explained in the code itself.

All done now...

Happy days! You passed all tests and can assume that the input is validated, sanitized and safe to send it to the database, files or other storage or processing locations.

Thats about it for the input validation process, client-side execution and server-side execution. Please bare in mind to never ever trust (user) input and always process it appropriately. The most common vulnerabilities are due to improper input validation.

I hope you like the set of posts on this topic and thank you for reading my blog!

Disclaimer concerning the code

Please be aware that the code above is merely an example to show what can be done to do input validation and it is not ready for production environments. Chances are that the regular expressions can be improved and other code might as well.

Always make sure that you follow the requirements of your applications and incorporate the security in its design. From there you can implement all the input validation you need for the best security of your application.

Sources

Here are a couple of informative and useful sources you might want to check out.

Copyright (c) 2015 Joram Teusink

MIT License

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Friday, October 3, 2014

Input validation for web-applications, how to process input safely and securely - Part 2 of 3

This is part 2 of 3 of the blog series about input validation for web-applications. In the first part the entire process was explained. In this post we are going to do some coding on the client-side, in this case Javascript. But keep in mind that the same principles apply to all programming languages.

Input validation is not only about security. It is also about building user-friendly applications (a message when the data-entry does not comply) and keeping data consistency (all data is stored in the same format). In example, you can choose to store all dates in yyyy-mm-dd format in your database. When you make sure you do that, you can easily analyze and generate statistics of the data in your database. When a user of the system enters data in a wrong format, you can either automatically change it (sanitization), or send a message to the user to enter it in the correct format.

Part 1 - Input validation process
Part 2 - Input validation coding client-side
Part 3 - Input validation coding server-side

The input form for registration

Let's assume we will make a small register form with the most basic input values. The following input is requested from the user, including all the requirements of the input data.
  • Name (name and surname)
    • Required
    • Maximum length is 50 characters
  • E-mail address
    • Required field
    • Needs to validate as email address
  • Password
    • Required field
    • Requires at least one lower and one uppercase letter, one digit, no spaces and a length of 8-16 length
    • Must be same as repeat password
  • Repeat password
    • Required field
    • Requires at least one lower and one uppercase letter, one digit, no spaces and a length of 8-16 length
    • Must be same as password
  • Birthdate
    • Optional
    • Needs to validate as a proper date (mm/dd/yyyy)
  • Personal website
    • Optional
    • Must validate as a proper url
    • Only http and https is allowed
Very basic values of course, but good enough for the example throughout the client-side and server-side input validation coding. It is very important to first sit down with your co-workers about the requirements of the data, before actually start coding.

Input validation Steps

For every step in the process we will look at what it might mean for Javascript. Some steps will not be required at all, some optional and some definitely required.
  1. Check if the input is actually sent and received
  2. Store input in memory, separate it from the source
  3. Check variable for, and remove all scripting
  4. Trim the variable
  5. Truncate the variable to the maximum size of expected value
  6. Check if it is the correct variable type and / or format
  7. Check if it is expected content (also called white listing)
  8. When relevant, check existence of local resources
  9. And now is it input for the process
All steps will be explained in the code examples.

If you want to go right away to a full example file, click here.

HTML first

On the client-side this step is not needed, but it might come in handy when you are building user-friendly (intuitive) applications. So lets start with the forms itself.

With the coming of HTML5 new field types are introduced, in addition to those already available with HTML4. Make use of those new field types. You will also notice the use of the pattern attribute in the input type element. Pattern makes use of regular expressions to validate the data that is entered in the form.

You don't need to worry about older browsers, as they gracefully degrade to normal text fields. Down-side of this is that some or all controls might not work anymore. So there will be still a need for JavaScript.

Then JavaScript

Before submitting the data from the form to the webserver it is key to validate it on the client-side first. This due to the various layers of defence. There is the form validation, there is the JavaScript validation and there will be the PHP (server sided) validation. You may not skip JavaScript if you think a browser will support the new form elements. Always include this step.

Disclaimer concerning the code

Please be aware that the code above is merely an example to show what can be done to do input validation and it is not ready for production environments. Chances are that the regular expressions can be improved and other code might as well.

Always make sure that you follow the requirements of your applications and incorporate the security in its design. From there you can implement all the input validation you need for the best security of your application.

Sources

Here are a couple of informative and useful sources you might want to check out.

To be continued...

That's about it for the input validation on the client-side. In part 3 and 3 of this series I will go more into the server-side (PHP) coding of input validation.

Thank you for reading my blog!

Copyright (c) 2015 Joram Teusink

MIT License

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.