All posts by Karlo Smid

OWASP, Ruby on Rails, security, security testing

Ruby on Rails bottom up security – hardening the servers

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

What I learned at Testival #30: learning by playing card games

2 Comments
Reading Time: 2 minutes

TL;DR

This post is about hands on session for learning about software testing using card games.

Intro

At TestBash Brighton2017, on Friday conference day, during the Lean Coffee, one lady ask question that you have probably already heard: “How should I motivate my team of testers?”

I suggested card games. Another participant immediately dismissed me: “I DO NOT LIKE GAMES IN SOFTWARE TESTING BECAUSE THIS IS NOT PROFESSIONAL!”

Noticed that this was his subjective opinion and he did not provide any arguments why is this bad idea. Well dear fellow software tester, this blog post is to prove you wrong.

Introductions

As usually, we started with 2-5 minute introductions. Every tester must be good at explaining things, so this is good way to practice that craft. We had new participants, 3 of them international. Meetup .com is powerful platform.

In this video extract, Priamo explains one concept from excellent book: “The design of everyday things”

TestSphere by Ministry of testing

TestSphere is deck of cards about testing concepts, 100 cards divided in 5 dimensions:

  • Heuristics: Possible ways of tackling a problem.
  • Techniques: Clever activities we use in our testing to find possible problems.
  • Feelings: Every feeling that was triggered by your testing should be handled as a fact.
  • Quality Aspects: Possible aspects of your application that may be of interest.
  • Patterns: Patterns in our testing, but also patterns that work against us, while testing such as Biases.

My point of view is that TestSpehere cards can be used for:

  • test plan
  • interview tester
  • share learning

TestSpehere also represents coverage of knowledge that skilfull tester must have. We randomly picked up green cards which represent technique. Each card has:

  • name
  • product level – hint how you should apply this card
  • three examples to seed idea flow

And magic happened! I handed a card to each participant and everybody had something to say about it. Which means we have the knowledge for software testing techniques, and TestShere cards helped us to structure that knowledge.

FluXX

FluXX is card game where rules and goals could be changed on every hand play. You have seven card types:

  • basic rule – draw one, play one. Game initial state
  • new rule – adds rule and removes existing rules if contradicts with them

Hmmm. Are those two rules contradict each other?

  • Goal card – how to win instruction
  • Creeper helps you to lose
  • Keeper helps you to win
  • Action – do something
  • Surprise

Note: play and discard card are two different actions!

How to play? Have one experience player and just play. Start from basic rule, everything else is written on cards (requirements!), but, you will have to think in order to apply them.

Fluxx helps you to practice all types of thinking in fast changing environment.

Game of Set

Helps you to practice multidimensional pattern recognition.

You have four properties: shape, quantity, filling and colour. Each property could have three values. Rule is very simple: you have 12 cards on a table, cards make a set of three if each of four properties are same OR different.

During gameplay I noticed that players usually forgot about one dimension, or they do not take into account that properties could also be DIFFERENT.

Have you ever tested something that has more than four dimensions? Our brain has system one and system two (more about that in Michael Bolton’s Critical thinking for testers.), you need to give system two time to wake up!

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather
learn testing, testing tool

Be careful with your testing tools

Leave a comment
Reading Time: 2 minutes

TL;DR

In this post I will describe how I got different test results using two testing tools Bug Magnet and Counter strings.

Bug Magnet is handy Chrome Extension developed by Gojko Adzic.

It is: “Convenient access to common boundaries and edge cases for exploratory testing.

Counterstings is implementation of James Bach algorithm that quickly reveals character position in string.

In my test, I used them to check maximal number of allowed characters in input form. This test should be simple, right?

One interesting thing happened. I first used Bug Magnet and inserted string with 128 characters. String was accepted and test failed because maximal allowed number should be 64 characters. I did second test with counterstrings. Boundary of 64 characters was successfully detected. What!?

What happened?

For me, any test should provoke sapient thinking process. In modern web applications, input form could be implemented in two ways:

  • html 5 standard, where all input constraint checks are done by browser code according to that standard

You can recognize this by inspecting input text box (Chrome developer tools) and if you see something like this:

<form action="/action_page.php">
  Username: <input type="text" name="usrname" maxlength="10"><br>
  <input type="submit" value="Submit">
</form>

then input textbox is implemented in pure html5.

  • using one of popular javascript frameworks (Angular for example, and that was the case with application that I was testing).

Then there is javascript code triggered on keyboard typing action. That code usually manipulates DOM tree to create better looking results.

Application created using modern javascript framework.

Bug Magnet is implemented in javascript, and it manipulates DOM tree in order to insert the test data. Be careful, because application user does not do that. Application user types directly into input box. Doing that manipulation, Bug Magnet managed to avoid string length check.

Counterstring uses Ruby on Rails code to generate counterstring on server side. It uses javascript to copy/paste counterstring to user clipboard. My input was done with copy/paste, something more closer to application user.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather
learn testing, testing tool

How to expose your reading list using rss

Leave a comment
Reading Time: 1 minute

TL;DR

This post is about how I manage blog posts reading list. It list tools that I use on daily basis to collect and share what I read.

My first try was twitter. I use it for collecting my blog post reading list by following software testers that blog about software development and testing topics. Here is my following list.

But very soon, twitter failed me. As they started pivoting their business model, very soon I received in my twitter feed a lot of noise (shares, likes, advertisement, flame discussions).

Then I turned to rss Google reader. RSS is old technology, and you can check if web site supports it by just adding /rss at the end of site url. No noise, no flame wars, just useful data. Notifications about new blog posts. But Google decided to shut down Reader (no advertisements rings a bell).

Rss reader market is not so big, and after short investigation, I found Newsblur . It has browser and mobile desktop and I use paid option (I think 27 us$ per year).

I have around twenty feeds that I am following (security, software development and software testing).

Another issue is how to share what I have red to support the author? I know, there is Twitter, Facebook. But my Facebook friends are mostly not connected with software development.

Here is how I share my reading list. Newsblur has it own share feature, one click away. It is called blurblogs. What I share, directly goes to my blurblogs page. That page also has rss feed. I expose it on this blog first page.

rss is old and very useful technology, give it a try.

 

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather
agile, learn testing

Safety nets

Leave a comment
Reading Time: 2 minutes

TL;DR

In this post I will present two examples of safety nets created by software industry professionals.

Note the context, I stated software industry professionals, which includes anybody involved in software development.

In Circus, trapeze artists have safety net to catch them if they fell. In modern software development, safety net for developers are software testers. Not to save their life, but to catch as many bugs as possible. In order to resolve that issue, companies started to remove dedicated software testers. Software developers are responsible for all software testing.

This is wrong from two angles. First, software tester job is not to find bugs but to provide information about software to people that matters (doing that, they also find bugs). Second, software testing is a craft that has SOME connection points with software development (writing automated tests). And usually, software developers are very bad at testing. I do not mean they write bad software testing automation code, but they are very bad in performing experiments (James Bach: “Testing is not about creating test cases. It is for damn sure not about the number of test cases you create. Testing is about performing experiments.)

During the Brighton TestBash 2017 open session day, I listened conversation between Anne-Marie Charrett and Paul Holland about safety nets. She consulted in company that removed software testers. They wanted to “cut” developer’s safety net. And guess what, developers found another safety nets.

I also have one example. I created a document with installation instructions. In order to avoid copy/paste effect, all commands were put as screenshots. Guess what? Software tester created his intermediate text file with those commands, so they could be copy pasted. As that created another level of documentation, those .txt files become very soon out of sync with main document that had screenshots.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather
testing tool

vim, show me your colors!

Leave a comment
Reading Time: 2 minutes

TL;DR

This post is about vim and how you can start using it in your daily work.

At one point in my testing path, I decided that I should start using vim. I opened Google, and start my search journey. I searched for:

“vim development platform”

What got my intention was search result:

spf13-vim – The Ultimate Vim Distribution

This is “spf13-vim is a distribution of vim plugins and resources for Vim, Gvim and MacVim. Which means that you need to install vim by yourself, and this distribution will add a set of useful vim plugins for development. Adding new plugin is also simplified (although, you need to know linux cat basics to do that).

For me, important one are related to ruby language. Here is one rspec file, opened in mvim:

Yes, you have coloured syntax. For me, this is very important, because with colours, I make less syntax errors!

Ok, you are set to go and you expenses so far are 0.

To get to know basic, run vimtutor (linux and mac os have it, for windows read this).

Here is set of vim cmd’s that I use on daily basics:

  • fire up vim: cd to your development folder and type: 
    mvim &
  • enter command mode
  • :
  • start folder explorer vim plugin (note, tab will complete your commands, so you can type Expl, then hit tab, and vim will do autocomplete
  • :Explore
  • open file in new tab
  • select file with arrow keys, then press t
  • close file
  • :q!
  • go to file bottom
  • G
  • go to file top
  • gg
  • go to end of line
  • $
  • go to start of line (this is zero)
  • 0
  • delete line
  • dd
  • undo action
  • u
  • start edit mode (you know that you are in edit mode when you see this in the bottom of vim

  • i
  • exit edit mode (you need to do that in order to do all other commands listed here
  • esc
  • delete character on the right
  • x
  • copy paste action. Note, if you start typing after you hit p, copied item is cleared from the buffer.
  • v, then with arrow keys make a selection, y, go to position when you want to paste, p, text will be pasted on the right of cursor
  • search
  • /, what you search, enter, found text will be highlighted, with n you move to next found item.

 

That it is. This is small set of features what vim can do, but for me it is enough to be productive!

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather
testival

What I learned on Testival #29 meetup

Leave a comment
Reading Time: 2 minutes

TL;DR

This post is about my learning experience on latest Testival meetup.

We had two talks and one 5 minute talk. We started with traditional introduction of every participant. Repsly was again event sponsor.

#1 Zoran Majstorović, ButterflyMX: Ruby Test Suite @ButteflyMX presented Ruby test ecosystem that his company use on daily basis. Those libraries cover whole testing pyramid.  Their web application is developed in Rails framework and they use following ruby gems (libraries):

  • rspec – test runner, automated checks and Rails mocks
  • FactoryGirl – test data
  • capybara – UI automation framework.

Code is on github, and they use branching and pull requests for deploy strategy.  CI system is Semaphore and Code Climate is set of open source Ruby libraries for code analysis.

#2 Marko Filipin, Head brewer and co-founder at Nova runda brewery: A/B testing beer

Nova Runda is one of the first Croatian micro brewery, they are known for their Indiegogo campaign through which they raised money to brew their first commercial beer, APA.

The best beer is one that always taste the same. Striving to that path, they started A/B beer testing. They presented two beers in three cups, A,B,C. They wanted to get statistics how many participants guessed which cups hold same beer. Participants were forbidden to do any commenting while testing the beer (no influence on other participants).

9 of 23 participants noted the difference. The number needs to be 12 so they can claim that they produced same beer in two different batches.

This is known as difference test. Preference test is subjective test. It gives answer which beer is prefered by the tester.

Yes/no test is acceptance test. Is this beer good enough to sell it?

What is beer quality?

  • from batch to batch, beer must taste the same
  • must have attributes of beer type. If you cooked Pale Ale, it must not taste like Indian Pale Ale.
  • ratio of sugar(malts)/bitterness(hops)
  • any not wanted tastes?

Zeljko Filipin presented problems with Vim UX in his 5 minute talk.

As a regular user of Vim, I suggest you to try this ultimate Vim distro. and start with basic tutorial found in Zeljko’s blog post.

 

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather
learn testing, speakeasy

Speak Easy program

Leave a comment
Reading Time: 2 minutes

TL;DR

This post is about my journey start with speak easy program.

During the CAST 2016 in Vancouver, I heard about speak easy program. That program helps you to compose your talk proposal for testing conference. It is voluntary based and created by Anne-Marie Charrett and Fiona Charles.

I applied in August last year.

On patient. When I asked my friend Zeljko Filipin how to make a good homebrew beer, he said: “To make a good beer, the most important part is patient”. With my third batch on the way, I found that it is true. Just to taste your beer, you need to wait for one month.

This month, I got speak easy feedback. I was patient because I knew that this is free volunteer based program.

After few emails exchanged with speak easy volunteer (I stated my time zone and most important testing topic which is at the moment Session Based Test Management) , I was assigned to Gil Zilberfeld.

He asked me a few questions to put me in software testing context, and we are set to go.

For start I need to pick three testing topics, which will be foundation for my future talk proposal.

Why I assigned for speak easy?

As when you want to learn some new framework or programming language, you start by reading and applying a book written by the expert from that domain. SpeakEasy will help me to get professional help from the domain of preparing and giving software testing talk.

Because I think that I have some valuable thoughts about software testing. My goal is to apply testing talk to permanent TestBash call for papers. TestBash is paid conference, and if I would be accepted, I own to participants to give my talk in the most professional manner. SpeakEasy will help me to do that.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather
learn testing

Screen size test strategy: always test on smaller screen

Leave a comment
Reading Time: 1 minute

TL;DR

This short post is about simple but effective test strategy that varies application environment: screen resolution.

When you test application, ask developers which resolution they use and then set the resolution for your computer screen to value that is less than minimal developers value. Screen resolutions have some standard values.

For example, if minimal developer resolution is 1440×900, you should set 1280×800.

Developers use large screens with big resolutions, so they are not best representatives for users of your application.

Using this strategy you will find corner view cases. If application view contains a lot of UI elements, then you issue will be dismissed. In that case, when you are testing again that application page, set you screen to larger resolution. But do not forget to set it back to lower one when you are done with that screen.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather
heuristic, rspec, ruby, testing tool

Bottom up Heuristic

Leave a comment
Reading Time: 1 minute

TL;DR

This post is about heuristic that I discovered while I wrote rspec ruby test script. Heuristic can be applied in any situation when you investigate errors reported on file line number.

One of my test frameworks includes Ruby where I write test scripts in rspec. I like rspec because it represents domain specific language (DSL) that makes testing code more readable and maintainable.

So yo have been in situation when you run your test suite, and you get test run report that contains line numbers where your check failed.

You need to update your test script. If you start your edit from top to bottom, your script will be no more aligned with test report. Now you have to run test suite again in order to align it again, and that takes time.

It is time for bottom up heuristic. Start your edits from bottom up directions, and you will keep your test report with test script. You will save some test run cycles and become slightly more productive.

 

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather