Pages

August 29, 2014

Support Of Inner Application

I don't know how many testers in the world are providing a support to customers, but in our company almost all testers are doing this.

We support "forced users" – by that I mean users, who are basically forced to use our application to do their job. For example, post office uses some inner application to register and track packages and letters, so post office workers are forced to use this application – there is no way they can do their job without it.
And by support I mean helping forced users to solve problems that they can't solve by themselves, to answer questions about some functionality or to modify data that can't be modified in the application.

Usually organizations that are using this kind of inner applications have their own IT support team. So application testers are actually supporting the support of forced users. The general process looks like this:
Forced user have some problem and reports it to organization's IT support team
|
Organization's IT support team try to solve problem and if didn't succeed report it to us
|
We try to resolve problem

I think there are six major features for this kind of support (these are also differences between forced and volunteered (Facebook, Gmail, etc) users):
  • Often forced users want to solve problem as soon as possible, because it blocks their job or makes it way slower – they can't work effectively if they can't deal with application.
  • Often IT support team is very busy (depends on organization), so they don't want to spend much time for one problem.
  • Forced users and IT support team are not random people for support. They are people with whom you work for years so it's long-term relationships.
  • In very most cases (just in case didn't write "in all cases") aim of forced users is to solve reported problem. Usually they don't report problems that doesn't concern them, they don't report theoretical problems (some security case that might happen 1 in 1000000) and they don't report problems to insult you or your application. They just want to do their job.
  • If IT support reports you a problem you can be sure, that they are already asked for help their colleges and basically you are the last instance that can help them.
  • Neither forced users nor IT support didn't choose to use your application, they just need to deal with it no matter they like it or not – just good to remember.

According to listed features I made main principles in support for myself (I didn't listed trivial ones):
  • I always try to solve problem in least possible number of replies. That means if answer depends on some fact that I don't know yet I'd rather give two options than ask for this fact. This principle helps to resolve problem quicker and doesn't force customer to do extra job.

    Bad example
    [Customer] Where can I modify the postal address?
    [Support] Which postal address do you mean?
    [Customer] Person's postal address
    [Support] [path to the component]

    Also bad example
    [Customer] Where can I modify the postal address?
    [Support] Do you mean person's or company's postal address?
    [Customer] First one
    [Support] [path to the component]

    Good example
    [Customer] Where can I modify the postal address?
    [Support] Person's postal address can be modified in [path to the component]. Company's postal address can be modified in [path to the component].

  • I always try to admit my mistakes "aloud". We are humans, we all make mistakes – sometimes I give incorrect information to customer (rare but happens). In that cases there can be temptation to hush it up and pretend that nothing has happened. Even if customer didn't notice or noticed but didn't tell you about some conflicts in your answers this may mislead him and he can remember this incorrect information, which leads to next possible misunderstandings in the future. So if I notice my mistake I'll tell about it.

    Good example
    [Customer] Where can I modify the postal address?
    [Support] Person's postal address can be modified in [path to the component]. Company's postal address can be modified in [incorrect path to the component].
    [Customer] Thanks, I needed person's one.
    [Support] Sorry, I wrote the path for the company option incorrectly, here is the correct one – [correct path to the component] (I know that you asked for person's but just in case)

  • IT support wants to learn how to resolve problems by themselves. If it's possible to resolve problem through application – tell them how, don't do it by yourself, so next time they can resolve similar problem on their own. If it's not possible – tell them why (it's not often necessary to explain all technical background, but some details could be given, depends on IT level of the customers).
  • Short specific comment is better than long polite text. Maybe this tip depends on culture of the region, but I prefer to write as short as possible, because it saves a lot of my and customer's time. For example, if they ask me to modify some data I reply with one word "Modified". If they ask me to delete some data – "Deleted". And if I have some questions or problems while performing task I write longer text with explanations. This kind of pattern helps to absorb information quicker.
  • If customer asks you to make some changes be sure that you understand the problem that he wants to solve. Maybe his solution is wrong or you can suggest the better one.


There is also second part: Support Of Inner Application, Part 2

August 12, 2014

First Steps In Security Testing

For about couple of months I've been interested in security and penetration testing. In my opinion, it's the most difficult area in testing at all, because it's the most technical one. The main challenge is to understand all processes, all data flows and all technologies, that are used in application. If you are in developing team, then it's a little bit easier – you can ask (or see, if you have admin privileges) some things, but it's still quite difficult to see and understand the whole picture of all processes.

Second challenge is motivation. Security bugs are not common ones, so you can spent a lot of time and effort (especially if you are a newer in this area) before you find some serious bug. As all bugs – not all security bugs are worth to fix. For example, if you can inject some SQL in admin component, which is being used only by one admin user, then probably project team doesn't want to spent time and money for fixing that (admin user can corrupt application and data anyway, event without SQL).
As a tester I am getting excited when I find bugs, not when I can see that application is pretty good. So for me browsing the application for 2 hours and not finding anything is quite boring. Which is bad for the project, I know, but I guess this is where the difference between tester and QA is.

The barrier to entry into security testing is quite high, however, the excitement of finding the security bug is also high. In my opinion, security bugs are the most important ones: better not to ship fully functioning but insecure software (especially if you have some payment system – even small possibility to loose money during transactions can be worse than delaying production).

And by security bugs I mean all bugs that violate one of the 3 characteristics:
  • availability – does somebody using this bug can disable some services?
  • integrity – does somebody can corrupt some part of the application?
  • confidentiality – does somebody can get access to information which he doesn't suppose to get?

So I decided to write some steps, which every tester can perform to check basic security level of you application.

1. URL parameters
Study URLs of your application. URL with parameters looks like this: https://www.somedomain.com?lang=en&accId=10054366&name=irinaivanova, where lang, accId and name are parameters and en, 10054366 and irinaivanova are values.

Basically, three cases are possible here:
  • URL contain some sensitive data, that can be stolen by third party. By sensitive data I mean password, legal code, telephone number. In our example, I would say that name=irinaivanova is sensitive data.
  • You can modify values of parameters in URL to access some third party data. For example, if you have log in system and you give id of account or user in URL, then you can try to change that id for random number – likely you will get the access to other account without any password (and get his privileges). In out example we have parameter accId=10054366, which stands for account id. You can see what happens if you change the value: accId=1, accId=0, accId=10054365 etc (bonus tip: admin account with all privileges will likely have id 1, -1, 0 or 10000000, where number of zeros can be taken from your account id).
  • You give info that is actually unnecessary. For example, such value as name you can take from database through account id. URL is not good place for spare info.

2. ID smart card authentication
In Estonia ID smart card authentication is very popular. If your application use this authentication you should test at least one case: log in with your ID card -> log out -> try to log in again in the same tab. I can bet that your application allows you to log in for second time and doesn't even ask the PIN code. This is actually browser plugin bug, not your application's, but it is possible to block second logging in without PIN code (for example, try to do same case in some internet bank page – you can't because they block second logging in in the same tab).

3. Cookies
If your application use cookies – you should test them.
Good article about cookies with simple test cases – Website Cookie Testing, Test cases for testing web application cookies?.

4. JavaScript injections
The simplest JavaScript injection is <script>alert('Vulnerability!');</script>. If you insert this script into field and process the form – you will get a dialog window with 'Vulnerability!' text in it, if your application has JavaScript vulnerability. Tip: it is more likely to execute JavaScript if you can save data in you application. For example, if you have field for name and can see this name in view mode, then try to insert script instead of name.
If you can execute such simple script that means that a bad guy can execute some more serious and harmful stuff.

5. SQL injections
Good article about SQL injections with examples – SQL Injection – How to Test Web Applications against SQL Injection Attacks.

6. Source code
Study source code in browser (mouse right click – View page source). Even if you can't understand the code you can note sensitive data, if there is one. For example, in the browser source code you can see JavaScript content, so your application should not contain data that you don't want to share in JavaScript variables.

Bonus: WTF character
There is such character as right-to-left mark. If you insert that then your further inserted text will be reversed right-to-left (it is used in Arabic languages). Beauty of this character is in his possibility to reverse the whole content of you page. For example, if users can insert comments on you page and somebody will insert this character, the whole you page will be mirrored and if you haven't heard about this character you will never know why! And it's really hard to find it in you database (to remove harmful comment).
I've already wrote post about it – WTF is this Character?



These are only first the easiest steps in security testing. I assume, that many testers have already heard about them, so I hope to write some more interesting and complex stuff as soon as I get smarter at this.