king-leonidas-this-is-sparta

Let’s Break Us Some Software! System Interface Attacks!

One does not simply break software. We have already learned that lesson well enough. Thus team of BugHuntress testing laboratory has decided to make this series of posts related to the fun part of testing that involves a lot of breaking things other people have worked hard on. Nice, right?

We have already discussed ways software may be broken through UI so we will now be discussing several ways of doing the same via attacking the system’s interface. Inputs, made from the file system are quite similar to the ones from a user. Yet there are more dangers lurking around as multiple applications are excepting weird user input when the files are expected to be quite consistent with this or that specified format. Mostly attacks here may be divided into two main categories:

  • Attacks based on media: meaning attacks that are simulating issues related to media storages.
  • Attacks based on files: issues related to properties of any particular file

So we may now move on to the chase and begin with our

Attack!

  • Try filling the file system to the limits of its capacity. Mostly developers are doing the required tests for this particular issue, but, sometimes… well… Simply fill the file system and try performing file operations. This test is easy and quite worth a shot.
  • Try making the media unavailable or busy. Many resources may be currently unavailable in any multi-tasking OS. What will your application do in such cases? Will it be waiting for a response, will it be locked or?
  • Try actually damaging the media.
  • Or you are always free to assigning any invalid file name. There may be multiple defects revealed within this step as there are often many file names that are restricted or forbidden by the file system or will be using common standards that the file system is using.
  • One important thing to do is verification of file access permissions. This step is mostly discovering subtle defects when the application is requiring most of general permissions.
  • Make changes to or even corrupt contents of files. This test will be simulating a process when data is being modified maliciously or by incident, like while transitions. There is a large amount of applications that are not checking for any error code.

Or you may try performing attacks via the Operating System as well.

  • Drain the amount of physical memory and make sure your app is handling itself fine in such conditions. Pro tip for the ones coding with C/C++: have you been checking your ‘new’ call returning to null lately?
  • The previous step is also to be repeated with various amounts of memory left for higher efficiency.
  • Try injecting network faults. This one’s great for testing performance. Simply explore some network traffic and make load on any particular port.
  • Surely there is a lot more to the subject matter but these ideas are quite enough t give you a head start.

TestFort Blog

About TestFort Blog

TestFort blog is an official blog of TestFort QA Lab company and is dedicated to various QA and software testing issues.


no comments yet

Be the first to comment this post!

Would you like to share your thoughts?

Software testing & QA blog by TestFort © 2017

×