Ruby on Rails bottom up security – Cross site scripting (XSS) check

Reading Time: 1 minute

TL;DR

This post explains how to check your Rails application source code for cross site scripting (XSS) attack.

Cross site scripting means that your application accepts html code as user input. Biggest issue is <script> tag, that allows user to execute javascript code in the context of your application. Second one is <img> tag that can also be used for code execution.

Rails by default escapes all input, which means that html code will be transformed, so browser will not interpret it as html:

<script>alert("Session based test management");</script>` => `&lt;script&gt;alert(&quot;Session based test management&quot;);&lt;/script&gt;

But some applications, such as github, allow users to have text formatting options.

Dirty way is to allow html input (github is using markdown language), and Rails have api methods for that:

html_safe

raw

This is ok as long there is not direct user input as parameter of that method (for your editor implementation, you also want to use markdown). Never trust your users!

Use this for code check:

grep -H -r 'html_safe' * | less

grep -H -r 'raw' * | less

There is one more important xss security attack vector. When you open link in new tab, application from that new tab can control, using javascript, application in original tab.

Use this for source code check:

grep -H -r 'target="_blank"' * | less

and make sure that link tag also has this option:

rel="noopener"

 

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Exploratory session of Pena Palace

Reading Time: 2 minutes

TL;DR

Using this excellent post by Marcel Gehlen , I am learning about exploratory software testing.  I created github wiki where I put notes about every resource listed in that post. This post is practical exploratory session of Pena palace located in Sintra, Portugal.

My vacation for end of this summer was Portugal tour, organized by Mondo Travel agency. Part of that visit was Pena national palace, located in Sintra town. As I just had read about session based test management by James Bach, I decided to practice it on Pena palace.

# CHARTER

Mission: Cover every walking path allowed to tourists in Pena palace and document interesting parts using Iphone 6s camera.

Note: When you do testing coverage, it is very important to state in report which coverage was done. Cem Kaner listed 101 testing coverage types, so please read it in order to know how complex is test coverage problem. By stating properly your testing mission, it is easier to estimate how much testing sessions is required.

I stated that I would do every walking path allowed to tourists. So no sneaking to restricted areas. Here are some other possible testing coverage types:

  • investigate every wall picture
  • investigate every palace window
  • investigate every palace door
  • investigate every tiles

# START

I know exact time that is when I took first Pena photo.

# TESTER

Karlo Smid

TASK BREAKDOWN

# DURATION

90 minutes

Note: This was “hard” requirement, because if I had exceeded that time, my group would have waited for me.

Timestamp of last picture

# TEST DESIGN AND EXECUTION
90%

# BUG INVESTIGATION AND REPORTING
0%

# SESSION SETUP
10%

As a group, we got info about Pena Palace from our guide. Also, I checked my testing tools, Iphone 6s and Iphone 6s smart battery case.

#CHARTER VS. OPPORTUNITY
80/20

Note: Kitchen looked very interesting. I would have definitely investigate it more if I had had more time.

# DATA FILES

# TEST NOTES

I managed to walk all available paths and document all items of my interest. When you go on vacation that is organized by agency, your are in the group and you need to adapt to given time. This is tradeoff. Positive thing is that you meet new people that have something in common: like to travel!

# BUGS

None

# ISSUES

None

In this post you learned about test coverage and how to apply session based test management during your leisure time. Have you noticed that exploratory word was striked through in TL;DR? James statement is that every testing is exploratory, so there is no need for exploratory word. And I agree with that statement based on my practical experience in last month when I applied my latest knowledge of exploratory testing.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Ruby on Rails bottom up security – authentication and session management check

Reading Time: 1 minute

TL;DR

This post is about checking “The Gates” of your Rails application.

Every web application is a set of urls. Some of them are publically available and some are available only to you (e.g. your bank account page should be available only to you and your spouse).

Modern web application authentication works as follows:

  • there is log in page where you enter your username/password
  • backend checks that combination
  • if this combination is valid, backend returns in Set-Cookie header long, unique, hard to guess string of characters. This is session string.
  • Browser takes that value and sends it in Cookie header in all following requests.
  • Backend checks cookie value and it needs to be same as one assigned to username/password combination
  • there should be logout endpoint that removes session string form username/password combination.

More about Ruby on Rails session security can be found here.

If you want to start your own session management, this could go wrong in infinity number of combinations.

So what can you do? Use Devise gem with following options:

  • store session in database
  • session must expire after some user inactivity time
  • log out feature must be implemented.
  • rotate devise key value (most frequently means more security).

In future security audits you only need to check devise configuration, that devise if updated with (possible) latest security patches and that devise security key rotation is active.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Learning risk management by example

Reading Time: 2 minutes

TL;DR

After taking state of the art software learning courses, I concluded that best way to comprehend knowledge is to learn by using examples of presented  materials.

How to measure quality of a course or workshop? For me, one metric are examples used in course or workshop. Of course, not THE NUMBER of examples, but my subjective measure how examples helped me to understand theory. And what is more important, how those examples help me to remember what I learned.

My examples of such courses are Rapid Software Testing  by Satisfice or BBST courses by AST foundation.

Today is SATURDAY and it was RAINY morning, and I drove to my hometown Zabok in EARLY morning. Security of my trip was jepordised on third stop light. Traffic lights were off. This was intersection with one direction road and intersection had road signs.

Should I wait for traffic lights be repaired? In that case, I will be late.

Since it was SATURDAY, EARLY RAINY morning, the traffic on the intersection was very light and it was intersection with one direction road, I crossed the intersection SAFER than on working day.

Ok, that was example, but what is the topic?

Your project is using a lot of 3rd party software components. Those components could have important security fixes. Deployment of new version for 3rd party component requires testing.

You are at YOUR crossroad with jeopardised security, this time of your product.

Should you upgrade? Will your sprint be late because of it? Do we need to deploy? Can project be secure enough without the patch?

This is security risk analysis for your product in the context of 3rd party component security fix. You need to create questions and answers in the context of your product and related to software security domain.

Can you give us any example?

 

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Ruby on Rails bottom up security – sql injection check

Reading Time: 2 minutes

TL;DR

This post will explain how to check your Ruby on Rails code base against sql injections [Wikipedia].

After you have read Wikipedia source link about sql injections, you are ready to proceed. It is important to state that Ruby on Rails offers one of the best (if not the best framework) out of the box sql injection protection.

But sometimes, developer needs to be able to override this protection for some “Twin Peaks” feature requests. In that case, even experienced Rails developer could make sql injection attack possible. On the other spectrum, if your company can only afford junior Rails developers, this check is a must.

Here is how you should hunt such protection overrides. First, head to Rails SQL Injection site. This page lists many query methods and options in ActiveRecord which do not sanitize raw SQL arguments and are not intended to be called with unsafe user input. You will use this site as a reference.

Open your terminal, go to root folder of Rails project repository, and use this cmd:

grep -H -r 'search for activerecord method' * | less

You need to replace search term with active record method name. Here you need to be creative in order to filter out results that do not represent active record method.

Here is the punch line:

Never, ever, trust the user input!

Which means that user input must not be directly used in active record methods. Again, refer to Rails SQL injection site in order to learn how to recognize code that is prone to sql injection.

Wait, but I am using Windows that do not have grep! Well, Google is your friend, there is a number of open source tools that will help you.

We also need to check all custom SQL queries using command:

grep -H -r 'execute' * | less

grep -H -r 'params\[' * | less

Same as for the active record methods, user input must not be directly used in custom SQL queries.

p.s. Twin Peaks feature request makes developer to have experience  very similar to experience of watching Twin Peaks: “The Return” [source].

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Testival 2017 second day report

Reading Time: 2 minutes

TL;DR

This post is about opening keynote and open sessions that I attended.

We gathered 40 software testers, which is 20% increase! Alex Rodionov open keynote was about Testers Anxiety. Which was hit to bulls eye because every software tester experienced that.

Software testers usually first spot contradictions in the product which makes them alert and that leads to Anxiety. Alex stated how can you identify that you are lousy tester, if there are bugs in product that you missed. Very simple. I like statement that programming is analysis decomposition, and software testing is composition analysis. Testing is like art. In testing, you should never stop looking for answers.

Then Alex switched to automation in software testing. He mentioned testing pyramid and asked question do we automate too much/enough? Do we trust our automation checks? Software testing is less deterministics and involves many checks, while in automation there is only one check. Then he explained model based testing that is smarter way to do automation.

My first session was proposed by me: What is exploratory testing?  Exploratory testing is so much overused that almost become buzzword. I realized that I can not explain what is exploratory testing. So I started making wiki notes based on this excellent blog post: Exploratory testing pathway by the Marcel Gehlen. I explained to the group what I have learned so far about Exploratory testing. In that way, I expanded that understanding (by teaching others, you also learn).

Second session was about software testing tools that we use in daily jobs and issue that we had by using those tools. I learned about Web Shaper and Charles proxy. Also, Chrome dev tool throttle does not give real results. There was idea proposed by Marko that it would be much better to connect mobile devices to “shitty router”.

During the lighting talks I presented Black Box Testing Machines that could be found in this excellent blog post by Katrina the tester. Post presents various games and puzzles that are used in teaching the software testing.

Zeljko presented Scratch, Vim, and why you should not go to the conferences.

Marko presented impressive set of Jenkins jobs and created on the fly new testing environment by clicking one job!

In UX testing session, discussion whent to the direction which tools are used for user behaviour analysis.

Last session was about state of the selenium. Selenium team will no longer support Browser drivers, that is now vendor responsibility. Selenium conf and Watir Bazar are excellent conferences and if you want to write maintainable browser automatization in Ruby, you should read Cucumber and Cheese book.

In closing session we shared our AHA moment and gave away a set of Test Sphere cards!

That was it! See you next year at Testival 2017!

 

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Testival 2017 first day report

Reading Time: 1 minute

TL:DR

TL;DR means too lazy to read (I got several inquires about that).

For contet of this blog post, Nova Runda is responsible party. This post is about first day on Testival 2017, free testing conference.

We had 33 participants, of which there where 12 influenced female testers. We have never emphasized problem of gendered diversity in software testing, but with honest approach  what is software testing, we attracted that number of female software testers.

What I like about Testival is that we have returning participants, and they brought new software testers. along So, open space event approach is good direction.

We started with introductions and proposals for open event slots. And guess what, no hesitation, no need that old Testival testers to start posting their proposals:

“Zeljko, we need to arrange those proposals according to number of votes” I asked. No need for that, participants done this by them selfs, they even created new rooms!:

 

We are starting tomorrow at 9.00 am with Alex Rodionov opening keynote. See you there.

 

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Ruby on Rails bottom up security – daily server check

Reading Time: 2 minutes

TL;DR

This is next post in series about Ruby on Rails security. In previous post I explained how to harden other servers. This time I will explain daily security check for CentOS servers.

After you securely set up your Ruby on Rails servers, you need to take care about their security on daily basis. Because time is the ultimate attack vector for all web applications.

Monitor Common Vulnerabilities and Exposures (CVE)

You need to create a collection of web pages that announce CVE advisories for components of your web application. Here is one typical Ruby On Rails application stack.

Next, check security logs that you had set up during the hardening phase.

Logwatch
logwatch | less
Fail2ban
fail2ban-client status
Selinux
less /var/log/audit/audit.log | grep AVC | less
Nginx log
log/nginx.access.log-YYYYMMDD*

This is where your application knowledge is important. In that file, I look for hacker patterns. First, I filter out regular application url paths, so what is left are robot scripts that are probing for known security issues for various applications.

For example:

zless /home/deploy/apps/betterdoc/current/log/nginx.access.log-YYYYMMDD* | egrep -v  'assets|images|favicon.ico|robots.txt|fonts

Note that I use zless, which is less for compressed files.

Do I need to restart servers?

There is a myth that you do not need to restart Linux servers after application update. Linux will not force you to do that, because running application would happily run with previous version. Which is bad if previous version has security issue. Remember, you set up automatic daily update for all server components. With command:

lsof -n | grep DEL | less

you will get a list of applications that still use in memory libraries that had been deleted from the server. If that command returns any list(DEL), you need to restart whole server (easier) or just the application that is listed.

In next post, I will describe security audit for Ruby on Rails application code.

 

 

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

It is Testival 2017 time!

Reading Time: 2 minutes

TL;DR

In this post I announce a software tester event, Testival 2017.

Testival is one day software testing gathering in unconference format:

""Typically at an unconference, the agenda is created by the attendees at the beginning of the meeting. Anyone who wants to initiate a discussion on a topic can claim a time and a space. Unconferences typically feature open discussions rather than having a single speaker at the front of the room giving a talk, although any format is permitted. This form of conference is particularly useful when the attendees generally have a high level of expertise or knowledge in the field the conference convenes to discuss."""[Wikipedia]

Why is for me this format better than regular conference?

As tester I ask a lot of questions, which is not possible at regular conference. Here is scenario: after the speaking slot, there is usually questions time slot, up to 15 minutes. This is time for the whole audience to ask questions. When this time is up, moderator usually announce that you can ask speaker more questions. But speaker is usually  followed by “groupies”, family or conference friends. It is very crowded and noisy, and usually I lost my question momentum force.

On unconference, there is no one-way-speaking part. Topic author gives introduction and initial questions/thoughts. And then discussion emerges. If it is not for you, use the power of two feet and move to another discussion topic (another room).

As an example, after the TestBash Brighton 2017 there was Open Space event. At the end of this event, I had fruitful discussion with Paul Holland and other participants about testing heuristics. He teaches Rapid Software testing and software testing heuristics are part of that class.

Bottom line is that in unconference format you are in control of discussions and you have a chance to shot much more questions!

Testival 2017 is in two weeks in lovely Zadar, Croatia.

We are starting on 1st of September, Friday at 18.00 by proposing discussion topics. Next day, on Saturday, we will execute those discussions divided into slots and across different rooms. Prior those discussions, we will have opening keynote by Alex Rodionov, one of the Watir contributors!

Location is Zadar innovation center. You can apply using this form and admission is free.

All relevant information could be found on conference page: www.testival.eu.

See you in Zadar!

 

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

The Black Swan event

Reading Time: 2 minutes

TL;DR

Yesterday I experienced negative Black Swan event. I will described it along with explanation what is Black Swan event.

This is explained in the book “The Black Swan (Taleb book) which is on my reading list. Every influenced software tester will recommend it.

“””The book focuses on the extreme impact of certain kinds of rare and unpredictable events (outliers) and humans’ tendency to find simplistic explanations for these events retrospectively. This theory has since become known as the black swan theory.”””[Wikipedia]

Yesterday I arrived home with combination of olive and engine oil on my sneakers. The risk: this significantly lowered traction between my shoes and ground, so there was high probability of fall.

I was in grocery store. There was funny smell in the grocery store. Then I heard crashing sound. One lady dropped a bottle of olive oil at the store entrance. I was in a hurry and did not wait for employee to clean this.

A few minutes later in public garage next to the place where I parked there was a car with big oil spill. Car owners were tourists.

My simplistic explanation (thinking about this event for five minutes).

It is highly probable that people drop things in this grocery store because they get sick with funny smell.

Yearly increase of tourist visitors in Zagreb is on average 10%. It is highly probable that you will meet tourist with broken car.

To conclude.

“””The main idea in Taleb’s book is not to attempt to predict Black Swan events, but to build robustness to negative ones that occur and to be able to exploit positive ones. Taleb contends that banks and trading firms are very vulnerable to hazardous Black Swan events and are exposed to losses beyond those that are predicted by their defective financial models.

The book’s position is that a Black Swan event depends on the observer—using a simple example, what may be a Black Swan surprise for a turkey is not a Black Swan surprise for its butcher—hence the objective should be to “avoid being the turkey” by identifying areas of vulnerability in order to “turn the Black Swans white””” [Wikipedia].

My robustness in this context. For last year of so, I pay extra attention to my shoes. They must have Goretex or similar technology, and advanced sole technology. Currently I am using Columbia Men’s Ventfreak Outdry Multisport Mesh Athletic Sneakers with Omni-Grip™ non-marking traction rubber outsole. The reason is my back pain and when I am wearing those shoes, I do not have back pain. By keeping attention to my back problem I also enhanced my robustness to explained Black Swan event.

Hmm, how can I apply that to my software testing?

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Blog that makes software testing interesting and exciting.