All posts by Karlo Smid

BBST, learn testing, Uncategorized

Learning risk management by example

Leave a comment
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, security, security testing, Uncategorized

Ruby on Rails bottom up security – sql injection check

Leave a comment
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

Testival 2017 second day report

1 Comment
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

Testival 2017 first day report

1 Comment
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
OWASP, Ruby on Rails, security

Ruby on Rails bottom up security – daily server check

Leave a comment
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
testival

It is Testival 2017 time!

Leave a comment
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
learn testing

The Black Swan event

1 Comment
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
Ruby on Rails, security, security testing

Ruby on Rails bottom up security – other servers

1 Comment
Reading Time: 1 minute

TL;DR

In previous post I described how to do security hardening for your Ruby on Rails web server. In this post I will talk about other servers: database, openvpn, cache and job.

Database server holds web application data so hacker will definitely try to get direct access to it.

You first need to do basic server hardening explained in my previous post. After that you need to be sure:

  1. that other servers port is not publically available
  2. access to other server is properly securely configured

One is resolved by putting your servers behind firewall. Second depends which server do you use. Here is example for postgres database server. Here is you strategy. When you know you database server, Google for its security settings and apply official guidelines that you will found.

How to securely connect directly to your servers? You can publically expose ssh port, but this is not good strategy. You need to use vpn connection.

OpenVPN

Simply explained, openvpn is ssh that uses certificate (public/private) authentication.  It will make hacker job much harder. You need one dedicate box with openvpn server.  Also, you will need openvpn client. So after VPN is set up, here is how you connect to your servers:

  • establish open vpn connection
  • connect using ssh to your servers that now have ip address from VPN network range

In next post I will explain how to do daily security check for servers and their software components.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather
OWASP, Ruby on Rails, security

Ruby on Rails bottom up security – web server

1 Comment
Reading Time: 2 minutes

TL;DR

In previous post I explained security hardening for linux server. This post will describe hardening based on server purpose.

Modern web application typically consists from following components:

  • web server
  • database server
  • job server
  • cache server

Security hardening for those servers is different.

Web server

Here are detailed instructions how to harden nginx web server.

  1. SELinux

SELinux is security kernel feature. If some component on your server is not patched, or there is Zero Day Vulnerability, SELinux will help you to protect other server components. For example, logging component has zero day vulnerability and hacker would use it to try to get access to your web server. SELinux adds additional level of kernel security to make that attack much harder.

2. Allow Minimal Privileges Via Mount Options

This is applied to partition that holds your web application files.

nosuid means that it will be not possible to change user and group permissions for that partition

noexec it will be not possible to run any program from that partition

nodev means do not interpret character or block special devices on
the file system

One of hacker attack vector is to serve his own malicious program using your web application. Those settings will make his attack much harder.

3. Linux /etc/sysctl.conf Hardening

These are low level linux networking and kernel parameters. First attack vector is try to login remotely to your server. These settings will make that job much harder.

4. Remove All Unwanted Nginx Modules

You need to run your nginx with modules that you need. Otherwise, your attack vector surface becomes larger.

nginx -V

will list current nginx modules. Here are instructions how to configure modules.

5. Change Nginx Version Header

This basically makes your nginx server more hidden. It will make hacker job much harder.

server_tokens off

How to change Server header. For centOS use

yum install

6. Install SELinux Policy To Harden The Nginx Webserver

These are selinux policies that will make your web server more secure.

7. Controlling Buffer Overflow Attacks

Buffer overflow attack is one of the first attack that will hacker try. There are special tools that help them (like Metasploit) to automate that attack. Basically, hacer will try to feed more data to web server connection. Setting explicit boundary values, you will make that task much harder. But be aware that those boundaries could influence your web application operations.

8. Control Simultaneous Connections

Set maximal number of simultaneous connections from same IP address. This will help you to fight web spiders and ddos attacks.

10. Limit Available Methods

You probably know about HTTP GET and POST methods, but do you know about OPTIONS? Restrict HTTP methods that are not used by your web application.

11. Nginx SSL Configuration

You need to run on SSL. For that you will need to buy signed ssl certificate.

12. Firewall

Your web server needs to be behind dedicated firewall appliance. Period.

That it is, security hardening for web server. In next post, I will talk about hardening for database server.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather
OWASP, Ruby on Rails, security, security testing

Ruby on Rails bottom up security – hardening the servers

1 Comment
Reading Time: 3 minutes

TL;DR

Next series of blog posts is about Ruby on Rails bottom up security. I will cover all aspects of web application written in Ruby on Rails framework. Described security concepts could be applied to any other modern web framework because we will describe which security problem particular concept resolves. I will start with hardening the server that runs the web application.

You probably think that hardening (reducing the surface of vulnerability) the server is impossible task. But I will prove you wrong. I found this excellent blog post that is foundation for hardening the server.

It has all instructions for Ubuntu linux how to harden the server. And you could be done with this task in 5 minutes!

Precondition is that server is up and running, and you know root password. You should first login as root.

  1. Select linux distribution

As you probably know, there are various linux distributions. I suggest latest CentOS for two reasons:

  1. it has excellent database about security patches
  2. it is tailored for servers that run server side services (e.g. web application)

2. Change root password

Unix command is

passwd

Tip. We suggest that you use LastPass password manager for creating and storing that password.

2. Update the system

You want to have latest software version as starting point.

yum -y -d 0 -e 0 update yum
yum -y -e 0 -d 0 update

3. Install fail2ban

yum install fail2ban

fail2ban is daemon written in Python that monitors suspicious activities and if detected, automatically bans client ip addresses for some time.

4. create new user

useradd deploy

mkdir /home/deploy

mkdir /home/deploy/.ssh

chmod 700 /home/deploy/.ssh

You will use only that user to connect to your server! Never use root user for establishing ssh connection. Note important command, chmod and number 700. At first, this look very cryptic. Read this for more info, and for now, remember that 700 gives all access ONLY to deploy user to .ssh folder (1+2+4 = 7).

5. ssh using public/private key authentication

In order to connect to your server, you will use ssh without password. How to set up that type of access? I recommend github tutorial:

Check for existing ssh keys is not needed, since you have new fresh server.

Generate new ssh key pair. You should set up password phrase (which is by default optional). Also, add private key  to ssh agent, so you will not need to enter password phrase. Be sure to store password phrase to lastpass!

Test your ssh connection.

Add your public key to the server. Previous link contains instructions how to copy your public key. The you have to paste it:

vim /home/deploy/.ssh/authorized_keys

Save file and run:

chmod 400 /home/deploy/.ssh/authorized_keys chown deploy:deploy /home/deploy -R

Mode 400 is read only. This is highest security, and without that mode, you will get cryptic error when you will try to establish ssh connection.

6. Test The New User

Keep existing terminal open, and from new terminal type:

ssh deploy@server_ip_address

7. Enable sudo

In your first terminal as root, first set deploy user password:

passwd deploy

Save deploy user password in LastPass!

visudo

You are now in vi editor. Comment all lines and add at the bottom:

root ALL=(ALL) ALL

deploy ALL=(ALL) ALL

That means when you will run sudo as deploy user, you WILL BE ASKED TO ENTER PASSWORD!

8. Lock Down SSH

Via ssh, you will not be able to:

  • connect as as root user
  • connect using password
  • connect from any client, but only from clients that you will list in setting.
vim /etc/ssh/sshd_config

Enter this, and be sure that original entries ARE DELETED:

PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy@(your-ip) deploy@(another-ip-if-any)
systemctl sshd restart

9. What about firewall ?

I strongly do not recommend that your server is directly exposed to the Internet. It must be BEHIND dedicated FIREWALL. Ask your IAAS provider about details.

10. Enable Automatic Security Updates

This should be set, at least for security update. Set it in cron to run automatically on daily basis.

vi /etc/cron.daily/yumupdate.sh

#!/bin/bash
 YUM=/usr/bin/yum
 $YUM -y -d 0 -e 0 update yum
 $YUM -y -e 0 -d 0 update

11. Install Logwatch To Keep An Eye On Things

Logwatch is tool that automatically monitors server logs and its logs can give you a hint about server intrusion.

yum install logwatch

vi /etc/cron.daily/logwatch_daily.sh

/usr/sbin/logwatch --output mail --mailto test@gmail.com --detail high

You are done with basic server hardening. In next post, I will explain how to harden servers based on their purpose. Web server, database server, cache server, job server have a slightly different security configuration.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather