Is Testing in India considered like Softwares’ in 70’s and 80’s?
During my last debate with a group of Enthusiastic Testers, I was hearing the same complaint. “Tester’s profile is considered as Scum job”. In a group of Software Engineers, there is always a vast comparison felt between Developers and Testers. Also when speaking to Potential New Comers into the field, it is very difficult to get a buy in into the Testing Domain. The reason given would be, there are inadequate challenges, the growth is very limited, the opportunities don’t exist or even worse “Testing Profile does not match my brilliance”
All I can do is laugh at the ignorance of words. I still remember my Uncle who always used to tell me how much he regrets of not entering the software field during his college days, but instead opted for Civil Engineering, a field only for the elite group in those days. I strongly believe this is the same scenario, currently in the Indian Markets. The Vision of Testers are still not fully known or the effects of Quality Tester is unrecognized. Yet this felling is curtailed only in the lower layer, as the Top management have already realized the worth of smart Testers.
When I look at Testing, I am always amazed at the vastness of this field. Right from Unit Testing, Module Testing, Integration Testing, Functional Testing, System Testing, Regression Testing, Performance Testing, Security Testing or Usability Testing, the field is vast. What is more interesting as Testers is, we have had a taste of each cup unlike in development where your knowledge is curtailed to certain domains.
If testing was so vast, challenging and interesting why has the market not realized yet. The Answer is simple. The Flood gates have just opened. People have just seen the trickling of water. This was the same Scenario as “Software in 70’s and 80’s”. The moment Testers start specializing in domains, the flood gates would wide open. With importance being realized in countries like US, UK and Germany the scene of India getting into race is not too far in the future. With abundant potential we are not far away from Seeing the next Boom. “The Testing Boom”
Friday, September 12, 2008
The Security Depth is inversely proportional to the Weakest link in an n – Tier Architecture
The Below Diagram shows a n Tier Architecture. To explain the data traversing between the layers, the diagram shows that data travels from presentation Layer to Business Logic Layer to Data Access layer. Our minds usually sees what it’s trained to see.
http://en.wikipedia.org/wiki/Image:Overview_of_a_three-tier_application.png
From the above diagram it’s obvious that if Security is heavy and 100% in Presentation Layer, then no data can traverse to next Layer and hence the system is absolutely Secure. Alternatively if the Database has heavy Security protocols, though Request gets passed from Business Layer it gets restricted in Database Layer. Hence the Data Traversing is Serial.
This is absolutely true and our minds are trained to think that the same serial access is provided to Security. Data needs to pass through 3 doors, and hence, “Security in one door is good enough.”
Alas when it come Security it behaves likes 3 parallel doors and not 3 Serial Doors.
1) Weak Presentation Layer but strong Business and Database layers – Let’s assume that Presentation Layer allows to User to mask himself as Administrator, then the User enters through the remaining 2 doors as Admin. E.g. URL sending userID with base64 encryption. Encrypt Admin UserName with base 64 and send it across to gain access. Pretty simple, but happening in most projects
2) Weak Business Layer – Most applications use IIS if MS technology is used. In IIS for sites, we usually use Network Authentication or we Give Application Pool with Standard User. Most Cases this Standard User is Super user to let communication happen via WebServices. If user gets restricted in Presentation Layer but masks in Application Layer, the layer gives complete Access to DB
3) Weak DB Layer – If no Logic is employed in DB or in Sprocs to check Authentication but give data for any Valid request, you can still sneak information.
Thus when it comes to Security it’s not 3 Serial Doors but 3 Parallel Doors. J
Note for the Week: Never trust Client Side Request or Web request.
Cross Site Scripting
Cross Site Scripting attacks (a form of content-injection attack) differs from the many other attack methods covered in this article in that it affects the client-side of the application (ie. the user's browser). Cross Site Scripting (XSS) occurs wherever a developer incorrectly allows a user to manipulate HTML output from the application - this may be in the result of a search query, or any other output from the application where the user's input is displayed back to the user without any stripping of HTML content.
A simple example of XSS can be seen in the following URL:
http://server.example.com/browse.cfm?categoryID=1&name=Books
In this example the content of the 'name' parameter is displayed on the returned page. A user could submit the following request:
http://server.example.com/browse.cfm?categoryID=1&name=<h1>Books
If the characters < > are not being correctly stripped or escaped by this application, the "<h1>" would be returned within the page and would be parsed by the browser as valid html. A better example would be as follows:
http://server.example.com/browse.cfm?categoryID=1&name=<script>alert(document.cookie);</script>.
In this case, we have managed to inject Javascript into the resulting page. The relevant cookie (if any) for this session would be displayed in a popup box upon submitting this request.
This can be abused in a number of ways, depending on the intentions of the attacker. A short piece of Javascript to submit a user's cookie to an arbitrary site could be placed into this URL. The request could then be hex-encoded and sent to another user, in the hope that they open the URL. Upon clicking the trusted link, the user's cookie would be submitted to the external site. If the original site relies on cookies alone for authentication, the user's account would be compromised. We will be covering cookies in more detail in part three of this series.
In most cases, XSS would only be attempted from a reputable or widely-used site, as a user is more likely to click on a long, encoded URL if the server domain name is trusted. This kind of attack does not allow for any access to the client beyond that of the affected domain (in the user's browser security settings).
For more details on Cross-Site scripting and it's potential for abuse, please refer to the CGISecurity XSS FAQ at http://www.cgisecurity.com/articles/xss-faq.shtml.
Cross Site Scripting attacks (a form of content-injection attack) differs from the many other attack methods covered in this article in that it affects the client-side of the application (ie. the user's browser). Cross Site Scripting (XSS) occurs wherever a developer incorrectly allows a user to manipulate HTML output from the application - this may be in the result of a search query, or any other output from the application where the user's input is displayed back to the user without any stripping of HTML content.
A simple example of XSS can be seen in the following URL:
http://server.example.com/browse.cfm?categoryID=1&name=Books
In this example the content of the 'name' parameter is displayed on the returned page. A user could submit the following request:
http://server.example.com/browse.cfm?categoryID=1&name=<h1>Books
If the characters < > are not being correctly stripped or escaped by this application, the "<h1>" would be returned within the page and would be parsed by the browser as valid html. A better example would be as follows:
http://server.example.com/browse.cfm?categoryID=1&name=<script>alert(document.cookie);</script>.
In this case, we have managed to inject Javascript into the resulting page. The relevant cookie (if any) for this session would be displayed in a popup box upon submitting this request.
This can be abused in a number of ways, depending on the intentions of the attacker. A short piece of Javascript to submit a user's cookie to an arbitrary site could be placed into this URL. The request could then be hex-encoded and sent to another user, in the hope that they open the URL. Upon clicking the trusted link, the user's cookie would be submitted to the external site. If the original site relies on cookies alone for authentication, the user's account would be compromised. We will be covering cookies in more detail in part three of this series.
In most cases, XSS would only be attempted from a reputable or widely-used site, as a user is more likely to click on a long, encoded URL if the server domain name is trusted. This kind of attack does not allow for any access to the client beyond that of the affected domain (in the user's browser security settings).
For more details on Cross-Site scripting and it's potential for abuse, please refer to the CGISecurity XSS FAQ at http://www.cgisecurity.com/articles/xss-faq.shtml.
Thursday, September 11, 2008
Software As A Service (SaaS)
SaaS is a new model of how software is delivered. SaaS refers to software that is accessed via a web browser and is paid on a subscription basis (monthly or yearly). Different from the traditional model where a customer buys a license to software and assumes ownership for its maintenance and installation, SaaS presents significant advantages to the customer. SaaS is faster and a cost effective way to getting implemented. There are no hardware, implementation or acquisition costs involved to run the application from the customer's side. It's the responsibility of the SaaS vendor (us) to manage and run the application with utmost security, performance and reliability. Since customers pay a subscription, they have immediate access to the new features and functionality. Unlike traditional softwares where upgrades would happen once a year or once in 6 months (with the vendor coming to your office with a CD), the SaaS vendor continuously pushes new updates, fixes to the application, which is immediately accessible by the customer. This reduces the length of time it takes a customer to recognize value from the software. Since the software application is delivered as a service, its important for the vendor to focus on customer service and experience. Since this is on a subscription model, the vendor is judged on a month-month basis and the pressure to innovate or risk losing business is greater. SaaS can be used by Windows, Linux, or Max users, providing true platform independence over the Internet.
“Thus as everybody sees, providing service over the Internet through TCPIP. Hence security is the biggest threat”
SaaS is a new model of how software is delivered. SaaS refers to software that is accessed via a web browser and is paid on a subscription basis (monthly or yearly). Different from the traditional model where a customer buys a license to software and assumes ownership for its maintenance and installation, SaaS presents significant advantages to the customer. SaaS is faster and a cost effective way to getting implemented. There are no hardware, implementation or acquisition costs involved to run the application from the customer's side. It's the responsibility of the SaaS vendor (us) to manage and run the application with utmost security, performance and reliability. Since customers pay a subscription, they have immediate access to the new features and functionality. Unlike traditional softwares where upgrades would happen once a year or once in 6 months (with the vendor coming to your office with a CD), the SaaS vendor continuously pushes new updates, fixes to the application, which is immediately accessible by the customer. This reduces the length of time it takes a customer to recognize value from the software. Since the software application is delivered as a service, its important for the vendor to focus on customer service and experience. Since this is on a subscription model, the vendor is judged on a month-month basis and the pressure to innovate or risk losing business is greater. SaaS can be used by Windows, Linux, or Max users, providing true platform independence over the Internet.
“Thus as everybody sees, providing service over the Internet through TCPIP. Hence security is the biggest threat”
Security Testing - Overview
Security Testing is quite a vast field. I had a different vision before I attended a training on Security, but the entire concept changed after the training. Visioning myself as a cool hacker (Just to note Hackers are people who want to improve Security by pointing flaws in code which have potential loopholes for crackers or hijackers to enter) after watching Die Hard 4, I had different opinion. I assumed it to be a pretty straight forward job for guys who are geeks. Alas hacking is not so simple, but extremely challenging and can be very frustrating at times.
[New] - Security Checklist and Report
Hacking is involved in 4 stages
1) Reconnaissance - To completely understand the application
2) Foot Printing Target - To create a sample application for Cracking
3) Discovering Vulnerabilities
4) hacking, Cracking or attacking.
Thus Security Testing also contains the same 4 steps except the last one. The last step would be replaced with
4) Providing Security Tips to avoid vulnerabilities
Hacking can happen due to these Major Reason
1) Weakness in Custom Application
2) Architectural Flaws
3) Flawed Design Configurations and Code
5 Classes of Code Vulnerability
1) Security Related Information
a) Weak or Non Standard Cryptography
b) Non Secure N/w Communications
c) Application Configuration Vulnerabilities
d) Access Control Vulnerabilities
i) Unprotected Database and File System Use
ii) Dynamic Code Vulnerabilities
iii) Native Code Loading
iv) Data Storage Vulnerabilities
v) Authentication Errors
Access to page through URL where no access is permitted by caching in Local M/C or Server
2) Input / Output Validation and Encoding Errors
a) SQL Injection
b) Cross Site Scripting – Unsuspecting Users to execute or access malicious code
i) Stored Attacks
ii) Reflected Attacks
Stealing Session and disclosure of information
Can be avoided by “HTML Entity Encoded”
c) OS Injection
d) Custom Cookie / Hidden Field Validation
3) Error Handling and logging Vulnerabilities
a) Insecure Error Handling
b) Insecure or Inadequate Logging
4) Insecure Components – Malicious Code
a) Unsafe Native Methods – Accessing System Resources Directly and not through Interfaces which pose threat id unsafe coding standards are followed
b) Unsupported Methods
5) Coding Errors
a) Buffer Overflow Vulnerabilities
b) Format String Vulnerabilities
c) Denial of Service Errors
d) Privilege Escalation Errors
e) Race Conditions
"The Path to a Secure Application: A Source Code Security Review Checklist"
Security in SAAS becomes of critical importance as then all details are now open to anybody over the internet. Thus the traditional methodology of speed, feature set and ease of use are not supplemented with Security and very soon Security will be of Highest importance.
The methodologies of Hacking are
1) Cross Site Scripting - 21% of hacking happens here
2) Injection Flaws - Traditional SQL injection
3) Uploading Malicious File
4) Insecure Direct Object Reference
5) Information Leakage - 73% of hacking happens here
6) Insecure Cryptography
7) Insecure Storage
8) Insecure Communication
9) Failure to restrict URL Access
10)Cross Site Request Forgery
11)Hidden form elements
Some Common Terminologies in the World of Security Testing
1) Phishing
2) Cross Site Scripting
3) SQL injection
4) Profiling
5) Same Origin Policy
Reasons for Hacking
1) For Fame to prove the world that you are the BEST
2) To Steal sensitive Information
3) To Deface a site, company
4) To plant Malicious Software for Gains
Security Testing is quite a vast field. I had a different vision before I attended a training on Security, but the entire concept changed after the training. Visioning myself as a cool hacker (Just to note Hackers are people who want to improve Security by pointing flaws in code which have potential loopholes for crackers or hijackers to enter) after watching Die Hard 4, I had different opinion. I assumed it to be a pretty straight forward job for guys who are geeks. Alas hacking is not so simple, but extremely challenging and can be very frustrating at times.
[New] - Security Checklist and Report
Hacking is involved in 4 stages
1) Reconnaissance - To completely understand the application
2) Foot Printing Target - To create a sample application for Cracking
3) Discovering Vulnerabilities
4) hacking, Cracking or attacking.
Thus Security Testing also contains the same 4 steps except the last one. The last step would be replaced with
4) Providing Security Tips to avoid vulnerabilities
Hacking can happen due to these Major Reason
1) Weakness in Custom Application
2) Architectural Flaws
3) Flawed Design Configurations and Code
5 Classes of Code Vulnerability
1) Security Related Information
a) Weak or Non Standard Cryptography
b) Non Secure N/w Communications
c) Application Configuration Vulnerabilities
d) Access Control Vulnerabilities
i) Unprotected Database and File System Use
ii) Dynamic Code Vulnerabilities
iii) Native Code Loading
iv) Data Storage Vulnerabilities
v) Authentication Errors
Access to page through URL where no access is permitted by caching in Local M/C or Server
2) Input / Output Validation and Encoding Errors
a) SQL Injection
b) Cross Site Scripting – Unsuspecting Users to execute or access malicious code
i) Stored Attacks
ii) Reflected Attacks
Stealing Session and disclosure of information
Can be avoided by “HTML Entity Encoded”
c) OS Injection
d) Custom Cookie / Hidden Field Validation
3) Error Handling and logging Vulnerabilities
a) Insecure Error Handling
b) Insecure or Inadequate Logging
4) Insecure Components – Malicious Code
a) Unsafe Native Methods – Accessing System Resources Directly and not through Interfaces which pose threat id unsafe coding standards are followed
b) Unsupported Methods
5) Coding Errors
a) Buffer Overflow Vulnerabilities
b) Format String Vulnerabilities
c) Denial of Service Errors
d) Privilege Escalation Errors
e) Race Conditions
"The Path to a Secure Application: A Source Code Security Review Checklist"
Security in SAAS becomes of critical importance as then all details are now open to anybody over the internet. Thus the traditional methodology of speed, feature set and ease of use are not supplemented with Security and very soon Security will be of Highest importance.
The methodologies of Hacking are
1) Cross Site Scripting - 21% of hacking happens here
2) Injection Flaws - Traditional SQL injection
3) Uploading Malicious File
4) Insecure Direct Object Reference
5) Information Leakage - 73% of hacking happens here
6) Insecure Cryptography
7) Insecure Storage
8) Insecure Communication
9) Failure to restrict URL Access
10)Cross Site Request Forgery
11)Hidden form elements
Some Common Terminologies in the World of Security Testing
1) Phishing
2) Cross Site Scripting
3) SQL injection
4) Profiling
5) Same Origin Policy
Reasons for Hacking
1) For Fame to prove the world that you are the BEST
2) To Steal sensitive Information
3) To Deface a site, company
4) To plant Malicious Software for Gains
Failure are not to be Feared but faced - Indian and Western Thoughts
I was discussing with my wife about a small project on Library management. After 2 hours of discussion she was extremely excited about the future of the project and its prospect.
The next questioned I asked her “What if you get a job tomorrow, will you take the offer?”. She answered “Yes, of course”. Though the answer was what I was expecting, it startled me.
She was sure about the success of the project, yet she would prefer a job (which could be boring) to the fantastic existing project.
The reason is “India Culture to Western Education?”
Indians are GIVEN the Receipe to Succeed, but Western Educators TEACH on How to Overcome Failure – Give and Teach
Don’t we know that “Failure is the stepping stone of success”, yet our culture has only taught us to follow roads to success. If the road was the reciepe to Success, tested and proved, where comes the question of failure? We all succeed but since we don’t know how to handle failures we do never take “Road less travelled or Road never travelled”
Google was a failure College Project when explained to entrepreneurs, until Google owners themselves decided to become entrepreneurs. The rest is Future to answer.
Oracle was a project dropped by US Defense, yet Larry decided to complete the project, only to become the second Largest Player in IT industry.
We might explain this phenomenon to US booming economy. Larry and Sergey Brin were not multi millionaires to accomplish the task. The difference was the belief they had in product and the energy to overcome failure. My own Client had failed 4 times to succeed the fifth time.
Indian Family Binding to Western Independent attitude
Does not India have the economy today? I now earn fair enough to sustain the family and my wife can take all the risks. Yet she believes in earning now, because she needs to sustain a better life style for the Family and Future kids. Probably she might have taken the risk, if not for the family. Westerners can afford to take the risk, because the failure does not adversely affect the “Family”. Though this might sound logical this is not true. Why so, because..
Indians should be taking more risks as we have a family to support even if we fail. But our Culture has never taught us to work with failure and failures are feared. In fact Failures are considered to signs of demons and bad omen.
Mahatma Gandhiji himself might not have succeeded, if he had not had western influence within him. His methodology was a Road never travelled, yet he believed, and more important he knew how to overcome failures.
The moment Indians believe in themselves and are taught to overcome Failure by not fearing them but facing them, we are not far from making India a Super Power.
Subscribe to:
Posts (Atom)