Saturday, November 29, 2014

Load a Bitmap efficiently and set it as a wallpaper for Android devices

In this blogpost I will open the parts of the source-code of my discontinued app called DroidPapers, that I considered as code making my app different from other apps. In the past I released other code to the general public, that were also a part of DroidPapers.

The topic is about Bitmaps and how to efficiently load them into your device's memory and, if needed, set them as a wallpaper.

The code is aimed at Android and written in Java and you need API level 14 (ICS) or higher. Perhaps with some tweaking it might work for other Java-based platforms and Android versions. But that is up to you.

Some requirements I had while making this code:
  • A Bitmap of any size should be loadable on any device, both low-end as high-end.
  • Make as less Bitmaps in memory as possible.
  • Free Bitmaps in memory as soon it is possible.
  • Always check if Bitmaps, and other variables, actually exists in memory before processing.
There are most likely even better ways to process Bitmaps. The code is based on examples found on the Internet and the Android SDK website. The experience I had with this code that error reports about memory hogging were gone.

The code is explained in the code itself. I made two files with one containing the "library" and the other containing the process of the Bitmap.

LibraryWallpaperBitmaps.java

ProcessBitmap.java

Thanks for reading my blog and if you have any questions, feel free to contact me or respond in the comments below.

Sources


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.

Saturday, November 22, 2014

The History of DroidPapers, from its start till its end

In this blogpost I am going to talk about my app DroidPapers, and its history. DroidPapers was a wallpaper and ringtone app and offered a service to automatically change the wallpaper of your device on a given interval.

Before I briefly describe a reflection with each generation of the app, I will first going to reflect on my experience with app-development and reasons why I stopped with my app DroidPapers.

Reflection, the good...

What a ride it was! When I first launched DroidPapers there were like two users. Me, and... well, probably someone else. Roughly 2,5 years later there were roughly 10.000 users per month with almost 200.000 pageviews and sessions in the app and website combined. These numbers were higher before, but later on that part.

In the year 2000 (or so) I had a website called photo4u.nl (not affiliated with the current website hosted behind that domain) and it affored a service to host photos for free. What was unique was the fact that it helped users to add the photos to their profile-based websites by generating proper HTML-tags. These tags could be added in order to show a photo (or image) on a profile or website. The most important part though was that it was the first Cloud service in The Netherlands for photos. Somewhere along the line I took a very very wrong turn and the website ultimately went offline (after being rather successful). Don't ask my why... it still hurts to much ;).

My creativity never died though as I was always busy with programming websites for myself or friends. Purely as a hobby to give my urge to be creative, to create stuff people want, a place to thrive.

Couple of years later the world met smartphones and tablets and my love for gadgets was born instantly. In 2012 I therefore decided to put my web-building skills in my efforts to create an app for users with love for Android or wallpapers in general. And this was the moment that the idea of DroidPapers was born. But there were already a lot of apps who offered similar services. So to make a difference, I made the wallpapers in my app unique. Only stock Android wallpapers were to be added.

After some time, it became a kind of boring, because Google did not release new wallpapers every month. Not that I expected this to happen by the way. So I started adding wallpapers from more sources to DroidPapers. The scope became original wallpapers from every device with Android. And to do something different, I added ringtones into the mix.

My app developed nice and easy and sometimes features were added, and even sometimes they were removed. In the last generation of DroidPapers most features were removed and the app became more clean and less cluttered.

I saw the usage growing, but it never surpassed 14.000 installs on devices and with 14.000 users it had reached its maximum potential. Nonetheless, I nice success that I created mostly by myself.

Reflection, the bad...

Not everything went well with DroidPapers. The first reason was technical. Due to my love for web-programming I decided to built my app with PhoneGap Cordova and jQuery Mobile. This way I could use my knowledge of HTML, CSS and Javascript for the development of my app. I think in the long run; this was a wrong decision. Don't get me wrong, I am not saying that web-applications are bad by nature, but for DroidPapers it was better to be a native written app.

The second one was copyright. After a while I contacted Samsung, Motorola, HTC, Sony, Huawei, and LG concerning copyright of their content such as wallpapers and ringtones. I asked them if I could have their content in my app DroidPapers. All replied (which was nice, thank you for that!), but all said no. In respect to their wishes all non open-sourced or free wallpapers were removed from DroidPapers.

And this decision (to abide by the wishes of the companies protecting their copyright) resulted in a big reduction of usage of my app. Many people understood my course of actions, but many went to competing apps or websites. Keep in mind that those services might not have explicit permission to host those wallpapers and ringtones.

Why stop with DroidPapers?

Well, to quote The Matrix: "Everything that has a beginning has an end." [The Oracle]. But there are better reasons though.

The first reason is time. Time, time time. If I could buy it, I would. I believe that the technical state of the current version of DroidPapers is outdated, especially compared to Material Design by Google. But I seriously do not have the time to change the entire code base, make the app native and rework all features in a programming language I yet have to master.

The second reason is career choice. My focus in the past year has changed to Information and IT Security. This very nice field of expertise within the IT-world (and beyond) has caught my attention, devotion and again, my time. I am starting a new platform (on which I will write in a next blog) focusing on Cybersecurity, well... just security. Let's all ditch #cyber.

And I cannot give proper attention to DroidPapers when I start other initiatives, but I also cannot give proper attention to my other initiatives when keeping DroidPapers.

And the last reason is funding. Hosting is not cheap, but I made a promise to my user base. There is no paid-content and there are no ads. Ever. So, wise or not, my funding dried out and the plug has to be pulled.

And these are the reasons that led to my decision to stop the DroidPapers service.

Can I continue it?

Well, you can if you want. You can find the entire source of DroidPapers on my GitHub repo and it is published under the the MIT License.

Word of thanks

First of all, I want to thank every user of DroidPapers, whether he or she still uses it or not. Thanks for making the app for what it is today. Thanks for all the review sites that reviewed my app and thanks for Androidworld.nl for making my app an app of the week.

Second of all, I want to thank Giampaolo in particular for translating DroidPapers to Italian. Thanks for all your time for translating and testing the app! Italian speaking people were the biggest group of users. Thank you all!

First generation

Begins with version 1.0
Release date: 27 June 2012


This was actually the first release of DroidPapers to the Google Play Store. It was a very basic app with one feature, setting the wallpaper as your default background. All wallpapers were included in the APK file and there were only Android AOSP wallpapers.

Second generation

Begins with version 2.0
Release date: 26 September 2012


This generation featured two major new features. The first one was the tablet and smartphone interface. And the second one was the addition of more wallpapers than only AOSP. With this release there was also a website built that hosted the wallpapers. The wallpapers itself were not included in the package anymore.

Third generation

Begins with version 3.0
Release date 10 December 2012

The third generation consisted of a couple of new features. Those were the favorites system, the service to automatically change your wallpaper and an updated framework of Cordova PhoneGap and jQuery Mobile. Also the interface got a nice revamp.


Fourth generation

Begins with version 3.11
Release date 11 June 2013

This generation introduced the side panel menu as Google ment it to be. Further more there were major technical improvements and the website was updated with better styling.


Fifth, and last, generation

Begins with version 4.0
Release date 3 September 2014

This generation introduced the cards based user interface and an updated website the get all user interfaces into one style. Many features were removed and some were improved.


The Statistics

The web-traffic statistics of 2012 and 2013 can be found below.


And for an impression on where DroidPapers was being used, check out this map!


Publication in the Android Magazine (Dutch)

And there has also been a publication in the Android Magazine on August the 13th of 2013 (number 13, page 65).

Want to see more?

If you want to see more videos about DroidPapers on YouTube, then check out this playlist DroidPapers.

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.

Friday, September 12, 2014

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

In this blogpost, one of a serie of 3, I will talk about input validation for web-applications. Input validation is a process that gets the input from the source (user, database, textfile, et cetera), checks it for any faulty and nasty and sneaky contents, and then sends it to the process that needs the input.

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.

This post is part 1 of 3 and is all about the process of input validation. Part 2 and 3 will contain code examples from PHP and Javascript for every relevant step in the process.

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

But first, lets take a look at OWASP.

OWASP

OWASP stands for Open Web Application Security Project. Their mission is to improve security of software. Short and fairly simple statement, but a very important one. They also track down the most often used (or rather misused) vulnerabilities that are present in (sometimes poorly) written software.

This is the list with the top 10 vulnerabilities in 2013.
  1. Injection
  2. Broken Authentication and Session Management
  3. Cross-Site Scripting (XSS)
  4. Insecure Direct Object References
  5. Security Misconfiguration
  6. Sensitive Data Exposure
  7. Missing Function Level Access Control
  8. Cross-Site Request Forgery (CSRF)
  9. Using Components with Known Vulnerabilities
  10. Unvalidated Redirects and Forwards
Source: https://www.owasp.org/index.php/Top10#OWASP_Top_10_for_2013

From that list the following vulnerabilities can be mitigated with proper input validation.
  1. Injection
  2. Cross-Site Scripting (XSS)
Two out of the top three of the most often seen vulnerabilities can be mitigated with proper input validation. That is how important this topic is. Please bare in mind that with input validation alone you will not be secure, but it is a big step forward.

The input validation process

I believe that you need to follow a certain protocol for every input you will process in your application. In my experience the following steps needs to be done.
  1. Check if the input is actually sent and received
    This check is to prevent any "null" or "not defined" errors when you execute step 2 in this process. If there is no (required) value being sent, the process can and should stop here.
  2. Store input in memory, separate it from the source
    Store the input in memory, for example a variable (no permanent storage!). This is to separate the input you are going to check from the actual source of the input. When you don't do this, the attacker might alter the data later in the process.
  3. Check variable for, and remove all scripting
    In this part we check the variable for scripting. Scripts in input variables might cause havoc on systems but injecting malicious code.
  4. Trim the variable
    Trimming is a process to remove all preceding and trailing spaces, tabs, and more of a variable. This keeps data in the database clean and helps with preventing a buffer overflow. Buffer overflow happens when you want to store a variable in a record, but the record is smaller than the variable and thus resulting in a buffer overflow which can be misused by an attacker.
  5. Truncate the variable to the maximum size of expected value
    This is the second step in preventing a buffer overflow. When all the spaces are gone, you will discard all data in the variable that exceeds the maximum storage of that record and its attributes. This step might be optional when you are processing data in text form, but think about this step thoroughly and carefully.
  6. Check if it is the correct variable type and/or format
    This step will check if you got the the type of variable you are expecting and if it is in the right format. Do you only expect a numeric value? Or do you expect a string? But also consider date-formats, URLs, and email addresses. This is the place to check for it. When incorrect you can either drop the input or convert it (sanitization) to the proper type.
  7. Check if it is expected content (also called white listing)This is an important and probably most difficult step to work out in the code when handling specific data. For example, in some cases you might expect an URL which always preceeds with "https://www.google.com/". So when you have received and processed your input, the last step is to check if you see that the variable meets your requirements. This is a content-specific check to prevent unauthorized data being send to your application. This can be different for every type of input in your application.
  8. When relevant, check existence of local resources
    This step is probably only relevant when you are processing input that is pointing to local resources. Think about files an user can upload, or an URL you convert to a local resource. In these cases, always check if the resource (file, database, etc) exists, before actually accessing it. The reason that this step is at the end, is to prevent malicious code being executed when you access the local resources on your web- or application servers.
  9. And now is it input for the process
    All checks are done, it is safe (as it can be) to process the input. This can be storing it in the database or presenting it the Graphical User Interface of your application. Don't forget to close the connection or resources you accessed in your entire process when you don't need it anymore.
Note: You can either check for invalid input and correct it (sanitizing), or reject it. What the best situation is for your application depends entirely on the use-case. Just keep this in mind.

When and where?

When this needs to be done? Well, that is simple. This process needs to be executed every time you receive input. Every time. Never ever trust input and never ever ever trust user generated input. I cannot emphasize this enough :). It seems an open door, but again, think about the top 3 OWASP vulnerabilities.

You can do input validation on multiple levels. You can do input validation server-side, but also client-side. For example, when you have an online form that users are filling in and sending it to your application, you can and you should do validation checks with every field a user fills in client-side. When the data is submitted, you perform a server-side input validation.

This improves the user experience in your application, and it contributes to the layered-defense principle. If the client-side defense layer fails (because the attacker is circumventing the form or regular ways of submitting input), you will have your second layer of defense ready, and that is the server-side input validation.

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 process itself. In part 2 and 3 of this series I will go more into the actually coding, both client-side (Javascript) and server-side (PHP).

Thank you for reading my blog!

Sunday, July 20, 2014

Cards user interface in jQuery Mobile web-applications

It has been a while since my last post about development. I was working on a new UX-design for my (discontinued) app DroidPapers, which was based (more) on the cards interface that we nowadays grow accustomed to.

There is a blog post that explains why cards are the future of the web. The author, Paul Adams, explains the basics of cards and the digital representation of it in web-applications such as Twitter, Google+ and more. Basicly cards give a nice structured view of your content, with the focus on your content.

There is also a post that describes implementing the “Card” UI Pattern in PhoneGap/HTML5 Applications. In this post the author, Andrew Trice, sets out how to make a web-app based on cards that can be used in PhoneGap and other HTML5 based apps. Some CSS coding in that blog is used by my code. The difference here is that this implementation won't lean on mustache.js and zepto.js, but purely on jQuery Mobile. The best part is that this uses already existing widgets.

The reason why I write this blog is that there is some tweaking to get a cards interface and since I could nowhere find a description for implementation in jQuery Mobile I thought, sharing is caring :). The cards are a bit a work in progress, so any improvements will also be edited in this post.

This post is by the way based on jQuery Mobile 1.4.3, and I expect to work it with earlier versions also. And obviously, this also works when your web-app is published with PhoneGap.

So here we go...

Before there were cards...

Cards appear to be existing from at least the 9th century, but I am not talking about those ones. I am talking about before the trent would be implement digital ones in the user experience of web-apps and native-apps. Let me take my app DroidPapers as an example.

This is how the current release looks like.
Opening screen, made with ListView widget
Overview with Android distributions, also made with ListView

The screens above make use of the widget ListView of jQuery Mobile and the modern look and feel of cards is completely absent.

Let's begin with grids...

So now we need to start coding. For the cards itself there is just some HTML and CSS coding needed. Javascript (or jQuery for that matter) is only needed if you want to dynamically make cards, which is also included in this post.

The base widget we need from jQuery Mobile is Grids, responsive grids to be precise. You can read more about these grids on the demo pages of JQM.

In this case we choose for a 3-column grid. It is possible to do larger (4 or 5), but it might look distorted on landscaped phones. Feel free to test it out for your needs though. Three is imo perfect for tablets, so it responds neatly with different screen sizes. A grid has no borders, no margins and no paddings, but the show it graphically, this is how a grid looks like.

An important note about using grid for cards. There are two ways to build up the interface.

Method 1:
The first 1/3 of the cards are placed in block A. The second 1/3 of the cards are placed in block B. And the last 1/3 of the cards are placed in block C. This will make sure that the cards will fill white spots when the screen is changing orientation and/or size.

Block A
Card 1
Card 2
Card 3
Block B
Card 4
Card 5
Card 6
Block C
Card 7
Card 8
Card 9

In portrait you would get first block A, then B, then C.

Method 2:
Create a new block for every card in a subsequent order. This will order the cards different then method 2. When you create new block for every card you would get an interface that is lined like a table.

Block A
Card 1
Block B
Card 2
Block C
Card 3
Block A
Card 4
Block B
Card 5
Block C
Card 6
Block A
Card 7
Block B
Card 8
Block C
Card 9

In portrait you would get first block A, then B, then C of row 1, and then block A, then B, then C of row 2 and finally block A, then B, then C of row 3.

In this blog post I will work with method 1, because it lines out the cards better.

And here is the basic code to generate that in jQuery Mobile. Make sure to include the CSS class ui-responsive.


So we now have a basic grid that responses to different screen sizes. The trick to make cards is making use of the DIV-element. If you came this far I expect you to now what you can do with div's and other HTML elements by the way. If not sure, check out this great resource: http://www.w3schools.com/.

Filling the grids with cards...

In every block of the grid you can place a card. The code for the basic card (without image) is shown below.

A basic card with no special options

It is also possible to incorporate an image. The code below shows how this is done.

A basic card, but now with an image

If you want to work with titles in your cards, that is also possible. You need to add the titles in the proper places.

A card with an image and titles

And if you want to add a banner in the image (in this case, the image new.png), then you need to make the code below. You can the download the new.png image here: https://github.com/triceam/cards-ui/blob/master/assets/images/new.png.

A card with an image, title, and the banner (notice the new in the right corner)

As the last part there needs to be a layout of course. Therefore you need the CSS code below.

Dynamically add cards in your interface...

Now we got the looks, lets make some code to dynamically add cards to your interface.

First of all, you will need to change your HTML code a bit. Not much, just add some ID-tags. So an example below.


The reason you need to add the unique ids are because in the code we going to use the jQuery selector to reach them. In the javascript below we are finally going to use the CSS code "div.holoPressEffectDiv". This to make the card give visual feedback when tapped.

The example below uses cards that are stored in arrays. It is also possible to use of API's, SQL databases, et cetera. Whatever you like :). You can find more information in comments in the code.

And how it will look like when you're done...

Cards with image and banner on the opening screen
The new overview with wallpaper distributions
And here how it looks on a tablet, with the same code!

How it looks on a 10.1 inch tablet, without changing any code!
You can find all code examples here: https://gist.github.com/teusink/3597bb0655c95b5a374e.

Of course you can mix some elements and tweak the code if needed. And again, with big thanks to Andrew Trice for his blog that helped me allot.

Thanks 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.

Wednesday, June 11, 2014

Terugblik op de Fox IT Cybercrime Symposium 2014 (Dutch)


Afgelopen dinsdag 10 juni ben ik naar het Cybercrime Symposium 2014, georganiseerd door Fox IT, in Den Haag (World Forum) geweest. De dag is als leuk, gezellig en vooral ook als leerzaam ervaren. Niet per se in feitelijke kennis, maar juist door een andere toepassing van diezelfde kennis. Met andere woorden, nieuwe inzichten en ook bevestiging van enkele bestaande inzichten.

Hieronder eerst een korte sfeerimpressie van het symposium.


De sprekers

De dagvoorzitter was Rens de Jong, ook wel bekend van BNR Nieuwsradio en RTL Z. De opening werd overigens gedaan door niemand minder dan Jozias van Aartsen, burgemeester van Den Haag. Hij onderstreepte het belang van cybersecurity (hoewel we zo onderhand van de term #cyber af moeten, maar dat valt buiten de scope van deze blog), en vooral ook het belang ervan voor Den Haag. Hij riep op om Nederland op internationaal niveau leider te laten zijn op het gebied van cybercrime en -defensie.

Of dat ooit gaat lukken weet ik niet, maar het past vanzelfsprekend wel bij onze kenniseconomie. We kunnen immers niet alleen leven van de verkoop van dijken en andere deltawerken. Aldus Jozias van Aartsen.

De dag werd gevuld door sprekers van CERT-EU (Freddy Dezeure), F-Secure (Mikko Hyppönen), ING (Jan Joris Vereijken) en enkele andere, maar natuurlijk ook mensen van Fox IT zelf, waaronder de founders Menno van der Marel en Ronald Prins.

Ruwweg allemaal met dezelfde boodschap waar ik in deze blog dieper op in zal gaan. Eerst wil ik nog even één bijzondere spreker toelichten, en dat is Mikko Hyppönen van F-Secure.

Bedreigingen van Staten en veiligheidsdiensten

Mikko kende ik niet, maar bleek tot mijn verassing toch een beetje een soort van legende te zijn. Hij werd geïntroduceerd als de persoon waar we eigenlijk allemaal op zaten te wachten op het symposium. Hij heeft onder andere de VS, EU, en Azië geholpen bij de grootste cybercrime uitbraken, maar is ook schrijver voor onder andere The New York Times. Daarnaast heeft hij ook nog gesproken bij het platform TED-talk en deze ervaring was absoluut te zien. Dit is vast de reden waarom VPRO opnames aan het maken was.

Maar wat maakte nu dan zo’n indruk? Zijn verhaal ging over malware. Malware dat wereldwijd op grote schaal werd en wordt ingezet. Malware dat geproduceerd is met nagenoeg ongelimiteerde budgetten en resources. Met andere woorden: malware gemaakt door overheden met als leidend voorbeeld de Stuxnet malware. Op een indrukwekkende wijze zet hij uiteen hoeveel de afgelopen 10 tot 20 jaar veranderd is op het gebied van spionage en malware. Overheden, zowel veiligheidsdiensten als de politiediensten, zetten malware in om doelbewust in te breken op machines en informatie te stelen. Dit is aldus Mikko niet per definitie fout (zeker niet met een gerechtelijk bevel), maar wel een punt waar je als individu en organisatie bewust van moet zijn.

Bijna vanzelfsprekend kwam het onderwerp Edward Snowden ook aan bod. De mening van de zaal werd duidelijk toen Mikko vertelde over een Amerikaanse politicus die zei: “Edward needs te man up”. Waarbij Mikko zei dat iemand die zijn comfortabele leven op Hawaï inclusief fotomodel-vriendin achter zich liet voor een principe de laatste persoon is die zich zou moeten “vermannen”. Na een seconde stilte volgde een daverend applaus.

Detectie, detectie, detectie…

Maar nu even naar de inhoud, de boodschap van het symposium. Het zou natuurlijk zonde zijn als zou blijken dat je een volledige dag (in mijn geval van kwart over 5 tot half 11) aan energie zou steken in een symposium, zonder hier wat van te leren.

Op het gebied van informatiebeveiliging zijn er tal van soort risico-beheersende maatregelen te definiëren. Zo zijn er preventieve, repressieve, correctieve en detective maatregelen. Al deze maatregelen verdienen aandacht, maar er is er één die in het bijzonder aandacht verdiend.

Uit een pol op het symposium zelf blijkt dat het overgrote deel van de aanwezige managers meer geld zou willen steken in preventieve maatregelen, tegenover de detective maatregelen waarin de ICT’ers en security-specialisten meer geld zouden willen pompen.

Een opmerkelijk verschil dat zich, aldus de sprekers en vervolg polls, ook vertaald in de dagelijkse praktijk. Naast de basis aan preventieve maatregelen (waaronder een goed security design, anti-malware, anti-DDoS, en meer van dat soort zaken), zijn er vooral detective maatregelen nodig. Waarom? Omdat de oorlog niet gewonnen kan worden met preventieve maatregelen, die per definitie al verouderd zijn en geen garantie voor een volledige dekking.

Zoals Jan Joris Vereijken van de ING ook al benadrukte, met detectie kun je ontzettend veel fraude en schade voorkomen. Dit omdat je verdacht en onverwacht gedrag kan herkennen en vervolgens hier passend op reageren. Bij de ING is men al zo ver dat hij verwacht dat inloggen in de nabije toekomst feitelijk niet meer nodig zou zijn (zeker niet om fraude te bestrijden). Een leuke en vooral ook gedurfde statement. Dat overigens wel past bij mijn gevoel dat inloggen met een account en wachtwoord een sterk verouderd concept is. Wie weet is er in de toekomst een goed alternatief.

Van intelligence naar response

Detectie staat natuurlijk niet op zichzelf. Want met detectie alleen win je de oorlog ook niet. Er zijn twee andere zaken erg belangrijk, namelijk intelligence en response.

Intelligence is het goed inzetten van de kennis die in de markt al aanwezig is. En dan betreft dit met name kennis over actuele dreigingen, mogelijke mitigerende maatregelen en ervaringen hierover bij andere bedrijven en instellingen. Goede intelligence leidt tot een goed inzicht wat je mogelijk staat te wachten op het gebied van cybercrime.

Vervolgens krijg je detectie. Monitoring op je omgeving is zodanig ingericht dat verdacht gedrag herkend kan worden. Wat is gedrag van een normale gebruiker, en wat zou weleens een hacker kunnen zijn? Op welke omgeving doet het zich voor en wil je gelijk ingrijpen of juist niet? Soms is het ook goed om even te wachten en te kijken wat er nog meer gebeurt. Dit vereist natuurlijk wel een robuust ingerichte monitoring met dito ICT-team.

Maar met detectie alleen kom je er niet. Er moet ook gereageerd worden. De toegang moet geneutraliseerd worden, er moet bewijslast verzameld worden en eventuele schade hersteld of beperkt worden. Dit valt in het stukje van response. Dit benadrukt het belang van een goede CERT (Computer Emergency Response Team) dat mandaat heeft om adequaat op signaleringen te reageren.

De boodschap is wat mij betreft dus: “Preventieve maatregelen zijn belangrijk en vormen de eerste lagen van je verdediging. Maar zonder detectie kun je aanvallen op je omgevingen niet herkennen en dit brengt extra risico’s met zich mee wanneer preventieve maatregelen niet afdoende blijken te zijn”.

Een geslaagde dag

Ik vond het al met al een zeer geslaagde en interactieve dag waarin ik nieuwe inzichten heb gedaan en waarin ik als vakspecialist mij uitzonderlijk heb vermaakt. Fox IT heeft een goed verzorgde symposium georganiseerd waarbij de opkomst overigens erg groot was. De zaal was vol, de aanwezigen deden actief mee met de pols en de dagvoorzitter heeft de dag op een leuke en respectvolle wijze geleid en was opvallend goed ingelezen in de materie.

Voor meer informatie over het symposium kan op de website van Fox-IT gekeken worden: https://www.fox-it.com/nl/bedankt-voor-uw-aanwezigheid-op-het-fox-cybercrime-symposium/