Posts Tagged ‘web’


Test automation and testability should be in same sentence. If the application is not testable, it will be hard to automate. This short blog entry lists few things which are benefiting the testability of web applications.

What kind of application is testable? The primary issue is that it is easy to test or it doesn’t need plenty of guessing. Test automation should be able to find easily the components which it clicks or edits. There should also be some easy way to check if the results are expected. Testable application aids to create test automation which tolerates the changes of the application.

Most web applications have forms. They are the most difficult part of test automation. Many modern web application frameworks are creating own strange names and ids for fields. When application is modified, the field names are change also or they can be more or less random. For example SharePoint based web application has field names like:’ ctl00_m_g_18447b1a_f553_3331_d034_7f143559a4fe_ctl01_stateSelection_input’. In worst case the content of field name is tied to session, or dynamically changed when page is revisited at later point of the test. Testable application should have simple and descriptive id or name parameter for input-fields and links. In this case it could b “stateSelection”. In most test automation frameworks it is much easier to refer to name-parameter than to some over cryptic xpath. It’s also more debuggable than e.g. //div[@id=’mainpart’]/table[0]/tr[1]/input[contains(@id,’stateSelection’].

Test should be able to assert if the response was correct or not. This is usually done by checking if some specific text or component is at the web page. To simplify the testing the html-code should be as simple as possible to avoid misinterpretations. It should contain e.g. html-comments to describe what the web application itself thought about the result. But no matter what the application does, it should never spit out the stack trace or some other error message which reveals the internals of application. That information belongs only to the logs. In error case the content should have something which can be easily linked to error log. It doesn’t help only the test automation, but it will also help to debug production time problems.

Proper server side logging and simplifying accessing to them increases also the testability. In case of failure the logs should have stack traces, exception information and other debugging information. It is very useful if test automation can retrieve these in case of error and add that to its logs.

Ajax is real pain for test automation, performance testing, manual testing and security testing. But developers and users love it! One major problem at Ajax is that web page loading is marked done before all content has been loaded. So it is very difficult for the automation to understand if the loading has succeeded or not. So there are couple things which should be done: First the agreement between testers and other stakeholders what is the maximum loading time the content can take. Second is some clear mark at dynamic content when it is loaded and rendered to the screen. This can be e.g. small comment at html-page. That way the test automation can have good timeouts, and it can detect the finished page.

This short blog entry describes just small part of web application testability. But my experience is, that these are the most common problems.

Advertisements

Session handling gone wild

Posted: 11.7.2011 in Security
Tags: ,

At web application (security) testing I like to investigate how sessions and cookies are handled. I’ve noticed that there are some common error patterns which are havocking the security of the session. Here’s brief list of the most common issues I’ve noticed. There is more issues than these five, but these are the most common once I’ve seen.

Randomness and length of session id are very important. If the randomness is poor or length is too short, the attacker can guess the session id which is already in use. I usually check this just in case. Luckily most of the frameworks are generating the session id internally, and developer cannot weaken that too much. But I’ve seen some coders creating own session handling, where length is too short. In that case different users are getting same session id and sessions gets hijacked.

When the authentication state of user changes, it is very important to change also the session id. Usually when user enters to pages without authentication, session id is generated. Even after logging in the same session id stays. This behavior is not very good. If the application were developed correctly, the first session id is given when user enters to web pages. When user logs in the session id is invalidated and removed from the user. During log in process the user receives new session id which differs from original one.When user logs out, the old session id is invalidated and new is created.

Too often I’ve seen that single cookie is used to authenticate user. That single cookie contains some kind of reference to user id and password, and it never changes. At application there can be session id which is secured, it changes as it should, it’s random enough and so on. But there is also cookie like XYZ_USERDETAILS which is some random looking string. When user logs out, session id is invalidated, XYZ_USERDETAILS is removed. But when used logs in again, the XYZ_USERDETAIL becomes same as it were after previous log in. Session id differs. If that kind of vulnerability exists, then if attacker can get the XYZ_USERDETAIL somehow, he can access with that information any time to target’s information. There shouldn’t be any static information which identifies the user.

Web application should always make sure that it is accepting only such session ids which are generated by it. I’ve seen many PHP applications which are accepting any session id which browser sends as long as syntax is correct. Instead of generating new session id it accepts whatever the browser is telling about its session and uses that to store session information. In those cases if attacker can get Javascript access (thru XSS) or local access, the attacker can set permanent session id for the browser which never changes. (Now I’m expecting that session id is not changed when user’s privileges change and web application never intentionally sets session id to empty.) So if browser tells that its session id is “aaaaaaaaaaa”, the web application must check from internal systems, that “aaaaaaaaaaa” is generated by it and is valid session id. If it is not, then system should change it to valid one.

Session ids (and all other cookies) must be protected as well as possible. There are two flags for that. If web application is using only https-protocol, then session id must be protected with secure-flag. Browser won’t send cookies with that setting over http-connection. If Javascript is not supposed to read it, then httponly-flag should be enabled.  From cookie security point of view the same domain should not be for http- and https-protocols. Mixing confuses the end user and prevents good cookie security. See e.g. Facebook from confusing system. If you don’t look carefully, you might end up to http-protocol even if you expect it to have https-protocol.

As the testers we should be familiar with basics of security and investigate what the application does below the user interface.


I started to think about putting this blog to life. It also needed upgrading the WordPress installation. Unfortuntely it wasn’t simple task as WordPress 3.2 is only supporting PHP5. Our hosting company supports only PHP4 with current hosting plan and changing that would require plenty of additional work. I’ve used WordPress.com for my Finnish blogs before, so I decided to move this also to there.

It is very simple to move posts and comments from your own WordPress blog to WordPress.com. You just have to use export at your blog and then import at WordPress.com. It asks you how to map the writers so if you have more than one writer, it’s not the problem to map them correctly. Author of comments are not changed any way if the author hasn’t been registered to your blog.

At the first stage I don’t want to move my domain badboysofquality.com to WordPress.com. I will do that at some point. So the tricky part is to redirect all requests from the old domain to badboysofquality.wordpress.com. I also want to make sure that permanent links are not going to broke down. At your WordPress installation you have .htaccess file. It is used by Apache to convert permanent links to form which is understood by WordPress. That file must be modified to redirect requests to your domain to WordPress.com. At the end my .htaccess is:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule (.*) https://badboysofquality.wordpress.com/$1 [R,L]
</IfModule>

Now all links to http://badboysofquality.com/ are automatically converted to correct form https://badboysofquality.wordpress.com/.

Is there any benefits to use WordPress.com instead of own installation? Yes. The technical maintenance time is reduced a lot. When I’m thinking the ‘costs’ of some service, I also do virtual charge from my own time 50€/hr. So if I spend time to tune own WordPress installation for 1hr/year, its extra cost is 50€/year. I also trust that WordPress.com will be more secure than own installation. It’s too easy to miss some important security upgrade. WordPress.com hopefully keeps its site more secure and up to date than I ever manage to keep with reasonable effort.

Is there negative sides? Yes. I don’t have control to WordPress.com. If I wanted to install some really fancy and cool plugin or theme, it would require a lot more money. I also don’t have control to ads the readers get. Of course I can pay to take them away. It costs only about $30/year. At the moment I don’t see any benefits from that, so unfortunately you’ll have to see the ads. At this first stage the domain is not my own. I will change that later. Its extra cost is only $12/year – not match compared to time I save.

So welcome to my WordPress.com version of blog. Have fun.


I have started to use cloud based tools to make my life easier. Here’s short list of tools I’m using and how I am using them. There’s most likely plenty of other tools which I could use, but these I use regularly. Do you have any cool tools to share?

Evernote is notebook cloud. It can be used with web browser and desktop application. When using web application, it is very easy store screen shots to there. I love that kind of feature. I have used it for article writing as well as for some blog texts. I can access to it even with my mobile phone. I haven’t done any security testing. You can use desktop application even so that you don’t sync your texts to server. It is also working very well without Internet access.

Yammer is for companies. It is much like Facebook with a lot less features. I have quite good trust to it because I’ve found only a few XSS-bugs. It is totally with https-protocol so it is not vulnerable for BlackSheep. We are using it a lot for internal information sharing of things which are not under strict NDA. It can be used even for free which is nice.

MindMeister is excellent browser based mindmap tool. You can share your mindmaps with others very easily. The access can be restricted to specified MindMeister users or put it to global use and protect it with password. I have really enjoyed it.

Google Docs is wonderful word processor. There is also other tools but I’m using it mostly with text. The best feature is possibility to collaborate. I can edit same text document with other people. I’ve fallen in love to that feature! I had wonderful time write one short story at it with my friend. I was ‘lead writer’ and she were correcting and adding some text. It was very well working. There wasn’t need to mail and have some old version.

Phun with redirects

Posted: 31.10.2010 in Security
Tags: , ,

I love redirection at web applications. They are so often broken. I’m trying to list here several mistakes which I’ve seen most often. Redirections are often used in places like login. That tries to make system friendlier for users by returning user to same page where he clicked the “Login”-link. So let’s imagine there is page ‘brokensite.xyz’ which has that kind of redirection. When user clicks “Login”, he is directed to page http://brokensite.xyz/login.jsp?returl=returnpage.jsp.

First: Lack of url validation. The attacker is able to set any url to returl-parameter. I usually try to replace valid destination with http://google.com/ and if I end up to that page after I’ve logged in, system is vulnerable. This should be one of the basic checks with web applications. In this case it would be: http://brokensite.xyz/login.jsp?returl=http://google.com/.

Second: Middle of URL %0A and especially with jsp. That is new line, and when redirection is made with http-result code 30x (302, 301 or some other). Then the target destination is given with Location-header. If the web application is not url encoding the destination properly, attacker can add new headers with %0A. And web browsers (at least Firefox) are redirecting to the last Location-destination. So in this case the attack URL would be: http://brokensite.xyz/login.jsp?returl=correctone.jspLocation:+http://google.com/

Third: Incorrectly escaped ” or ‘ when redirection is done with META-tag or JavaScript. Those cases are more like XSS or html injection errors. But still they can be very effective. Usually the mistake happens with META-tag. Developers tend to forget that proper quote escaping is not with backslash at tag-parameters. Let’s expect that quote is now escaped wrong with backslash so ” at parameters are converted to \”. Only characters ‘ and ” are escaped.

To produce result below our url must be: http://brokensite.xyz/login.jsp?returl=correctone.jsp?”<script>alert(1);</script>.

<META
HTTP-EQUIV="Refresh"
CONTENT="0; URL=correctone.jsp?\"><script>alert(1);</script>

Fourth: JavaScript-redirection is not properly escaping character combination – -> or ]]> – depending what kind of hiding is used at JavaScript. Those are usually ending the JavaScript hiding and also escaping from quotes. So JavaScript below is totally legal. It is created with url http://brokensite.xyz/login.jsp?returl=correctone.jsp+- -></script><script>alert(1);</script> (remove the space between dashes. WP seems to combine multipe dashes to longer dash.)

<script><!--
window.location="corretone.jsp --></script><script>alert(1);</script>");

//-->
</script>

If you are developer and plan to make redirection, please, use response codes instead of JavaScript and META-tag. The JavaScript is most vulnerable type of redirection. And META-tag can be turned off too easily. Always URL-encode everything you receive. Never trust to anything which is coming from the browser. Testers – like me – can be evil, but criminals can be even more evil.

Why redirection errors are bad? Well – thanks for the insecure SMTP-protocol, phisher can send to victims the mail with from-address admin@brokensite.xyz. Mail says that account has been suspended and requests the user to login to http://brokensite.xyz/login.jsp?returl=attackers_own_url. And that can insert malware, steal password by telling that user gave wrong password and requests to resubmit the password and so on. Attack possibilities are nearly unlimited.