1)  ”http://www.paypal.com/en/cgi-bin/webscr?cmd=_logout” – it you go to this url while logged in, your session is terminated.

Possible exploit: you can create a repeating (hidden) script (maybe on some webpage) – so that the user will believe he/she cannot login at all.

2) I am able to send money and create accounts for emails starting with “%”

Example “%john@testxcvdf.com” (You can check it for yourself – Password is “!QAZ2wsx”)

Possible exploit: the fact the char is not validated, might be considered a weak spot for hackers, by trying different alternatives.

Even if both issues are not exactly a problem, it shows that they didn’t do some type of needed testing.

(I am going to send this to their support)

Edit: Ok, I got a simple script as example for the logout issue

Steps:

1) Open this url http://www.testalways.com/exploits/1.html (reloads an iframe with the link)

2) In another tab/window of the same browser login into the Paypal account (you can create one just to test it – you don’t have to enter any private data)

Behavior:  User is disconnected quite fast without realizing what is going on

Conclusion: The value of a bug might depend on possible exploits.

This is an example of a behavior that is known, but maybe not much thinking was done in relation to security.

Another thing is the usage of same libraries for developing web applications. These bugs are identical to issues I found for a previous client.

With it I was able to hack into one of my client’s web server (literally the server that hosted the web application) and was able to create folders and  delete files.

The script can be used for hacking a web application in places where you can upload images or any other files.

Example of a scenario:

1) Check if the web app has a section to upload an image (usually user profile)

2)Use an image with a specific name that you can recognize and upload it

3) Check after upload and storage where is the image now located (check if the name is intact ; check if the size is the same )

4) If the image is stored with the same name or is not altered, you can try uploading the knull-shell script and the check the url

5) if the url of the stored file ends in …/some_location/knull-shellv1-beta.php and permissions are set badly, you can try to execute that script by opening that url

6) If you are successful you should have something like this:

Username: root

Password  :toor

and you should have something like this

Now you can try to see how far you can go!

I believe overall the past year was very good in relation to my testing experience.

The details are important, but can change, that’s why I tent to set general goals (it also gives more options to use as a solution):

• Find suitable ways to keep being known in the testing field. This is important especially in finding new clients. But not only there:(also) government paperwork, renting/buying a house, dealing with a bank, unblocking quickly the Paypal account , general trust in many situations…
• Deal with the particular problems that might appear while trying to raise a reputation: more responsibility, accepting constructive criticism, detect and reply properly to nonconstructive criticism
• Continue learning about testing. The more I learn, the more I think I know less. But its still a good feeling
• Do the best job I can do with the clients, so I can bring value to them
• Do the best job I can do  at the conferences I was invited this year
• Solve anything that might come on the way

The city of Bilbao is awesome at day and at night. It looks very calm and relaxed, not like a very big metropolis. I enjoyed the Guggenheim museum visit.

I couldn’t relate to all the presentations there, but definitely is a way to see what is done in the testing industry in some parts.

Did my workshop in the second day, using an application that you can find here www.testalways.com/Bilbao/. This presentation had the purpose to show a test project in a simplistic way, in which cost, risks coverage have to be considered like in a real situation. It used gaming and interactive ideas from James Bach and Michael Bolton. My skills and way to show it are not close to theirs. So I prefer to take the criticism for the bad part and they deserve the credit for what is good.

Met some interesting people like Michael Stahl, who Shmuel recommended before; Malini , which I knew from the EuroStar video competition I participated and who gave nice words for my workshop; Ray Arell seems like a nice person to talk to; also the other great people I’ve met that I don’t remember now. Thanks for all who tweeted related to my workshop.

Thanks also for the organizers  Software Quality Systems S.A.(SQS) who did a very nice job.

The event took place in Hamburg and it was my first trip there. The city seems like a nice place, where everything gives the impression of cleanness and organized work. If you want to try something excentric, Reeperbahn at night is the place to be. Therefore, you can select what you consider suitable for you.

The workshop had a few participants, Meike Mertsch, Markus Gärtner, Maik Nogens , Christian Baumann and myself, but it turn out to be a really productive and interesting meeting. Some of the initial topics were more developed than others, turning the discussion to focus on only some aspects ,and thus, causing other topics to be left out, but for some other time. It was a really good stimulation of the brain.

In some workplaces and most corporations you are just limited. When you have the chance to do a little bit more and add a personal touch to your work, something happens and you end up being busy with other secondary tasks. Meetings and workshops are a great opportunity for the testers, in this case, to come with new ideas and more important, have their ideas put into practice.

Therefore, I thank Markus and Meike’s company it-agile GmbH for making the event possible, by letting us use their space, and because I had the chance to meet interesting people in the beautiful city of Hamburg.

Markus’ session with the dice game, done by Michael Bolton and James Bach particularly comes to my mind as I have to admit that I didn’t really recognize the pattern instantly, even if it was the same James practice with me more than an year ago. And then I thought that my solution was expressed mostly by numbers and it could have been represented in a visual way. Thus, I realized visual memory is stronger than memorizing numbers.

You can check Markus blog post on it for more information, blog to which I couldn’t add too much myself.

Maik had a nice story in which he described the notion of “Charity Testing”, a term that he coined. Basically, if you want to learn for yourself, the best approach is to use it in a specific context, by finding projects that are done to help the community, as a volunteer tester. Although maybe “volunteer” is not the exact word.

Meike played a lot with stickers and kanban. I personally took from this a sketch idea for future implementations as puzzles or even ways to write an article.

I also tried my beta picture puzzle exercise, but turned out to be a bad idea not to mention that it was not complete. Of course everyone in the room was a tester and my app was thoroughly analyzed and broken. It got a set of bugs that I wasn’t aware of, but will try to fix it.

The topics presented were interesting, but what was really great it was the way the whole workshop went and ideas changed.

It will be harder probably to keep the same spirit of sharing among larger number of participants, as in large crowds you have lesser time and tend to self-censor yourself about what can be said or not. But, I would gladly participate to a second workshop next year.

As I said, the subjects and topics were good, but what really matter was the way we shared the ideas. If there is a job where one can have this constant environment of sharing ideas and come up with better solutions every day, I would really like to have the chance to experience this once again. I realize, however, it is hard to find such a thing.

The mission had the purpose of doing  self-training activities related to Weekend Testing chapters.

Basically each participant had to edit this document Charters-How-To with the scope of improving it.

More details on http://weekendtesting.com

Even that I proposed the mission and got to play a little before the actual meeting, I think I got more knowledge about boundary testing and limits.

Everything will differ for a product and environment, but in this context I saw:

-a chat message goes through many locations. As we assumed (read the transcript) it will be probably be an Xml record at one point, then maybe a db record. Depending how the data stream is sent, we will probably have another set of limits.

-in testing limits we can actually do (without even trying)  security testing or Pen testing. So we should be also careful from the legal points of view.

-the boundary depends on the input. An alpha numeric char differs from another char. An example used were kanji (Japanese) chars (“Petteri Lyytinen: I tried to paste a text string that is 32768 kanji characters” ..”only showed the two dots”)

-anything too big is truncated (or should be truncated in some situations) and the process of truncation can be different in some cases, some unexpected

-some parts cannot be tested easily (or in the required time interval) like the history containing large messages

-tools help – this time we used one available, but in other cases tools need to be built up

Thanks to the participants:

Anna Baik, Ben Simo, David Vydra, Kristjan Uba, Lalitkumar Bhamare, Michael Larsen, Narasimha Reddy, Nitin Purswani, Petteri Lyytinen, Santhosh S Tuppad and Eusebiu Blindu (as host)

The first question someone would ask is “Why?” Well, because a Weekend Testing session can provide several nice stuff that usually is not present (or not in the same way) as in a real job:

-you can just not participate (but this “free will” increases the chances of enjoying it and get something productive from it)

-usually there are simple applications to understand for all – and from this what remains is the way to develop an approach to test it

-its a way to spend time (maybe not the best, but not the worst)

-you can risk with stuff you cannot risk at work – like following the curiosity for an approach

-get others to know you (usually the after reports include mentions to your name – website links if you are easy to be found )

and many other stuff

Anyone is welcomed to participate and this is possible by:

- Looking on the WeekendTesting website, usually the announcements are here for the new sessions

- adding on Skype the username  “europetesters” in your list

- sending an email at europetesters@googlemail.com

- following @europetesters on twitter

According to The Elements of Journalism, a book by Bill Kovach and Tom Rosenstiel, there are nine elements of journalism.

So I though of proposing myself a similar set for testing:

1. Testing’s first obligation is to show the truth.

This means to take off the veil of fake certainty that everything works. Also to validate any assumptions claiming there is nothing that reduces the value of the product.

2. Its first loyalty is to the client(s).

Here the clients can be users,  stakeholders,  managers. Its important to know who are the clients in the first place.

3. The essence of testing is questioning a product in order to evaluate it.

This is actually inspired from the definition that James Bach gives to testing.

4. The testers must maintain an independence from the people that give them the info.

For example the data gathered from a developer should not be trusted 100 percent. People will give you what they think or what they assume is right.

5. The testers should inform based on their analysis and thought.

This means they should not just take the info they receive and jump to use it to inform others. If initial information is false,  it will result in more disinformation.

6. The information provided by testers should be also reviewed.

This means a bug can be set invalid, or the reports should be reviewed by someone else.

7. The information about the product to test should be significant, interesting and relevant.

Testing should consider risk areas, priority based on circumstances, context and the  information should be useful.

8. The information provided should be comprehensive and proportional.

This means to inform the client right to the point, also in an acceptable format. No one will read a 100 pages report when its not needed.

9. Testers should be allowed to exercise their personal conscience.

This means the approach should be left for testers to decide  and have a relative independence.