Is Software Security Testing Complicated?

Testing software for Security is something that can be quite complicated to do. Those that do test software are also those that have taken classes and know just what it is that they are doing.

If you are all into software, and are very familiar with it, as well as interested in testing it yourself, you are going to want to check out the software testing course that is held closest to you.
Many companies hire a 3rd party to give their employees a security testing course or build an in house team for providing this as a special service to teams across the organization.

I somehow believe that Security testing is something that comes a little easier to someone that understands or has written a software program before. If you have ever written a software application and are looking to get into testing, you are going to find that learning what you need to know to test will be easier for you than someone else.

Is virtual keyboard been considered?

Phishing is an attack where the attacker sends a mail making it look as if it has come from a bank or a financial institution and lures the victim into entering his sensitive information.

Image based keyboard (or virtual keyboards) were invented to make life harder for banking or phishing Trojan horses (specifically key-stroke loggers or key loggers), some even suggested they be used specifically to avoid these Trojan horses.

Clear Text Secrets

We often find applications storing secrets in a non-encrypted form which presents a severe security risk. If an attacker was able to retrieve & read the secrets, it could lead to compromise of the application, host or network, loss of revenue, loss of confidence of the user with the application.

"Sensitive"data like User Credentials, cryptographic keys must never be stored, cached, or sent unencrypted. For instance: logon passwords, PINs, credit card numbers, telephone calling card numbers, session ID that can be used to gain access to goods, services, or confidential information must always be stored and sent encrypted.

Avoid using proprietary encryption algorithms. Use trusted and proven standard algoriithms for encryption and have key lengths of at least 128 bits. Secure Socket Layer (SSL) must be configured to use at least a minimum of 128bit encryption and must not be allowed to fall back or accept weaker levels. Applications which use SSL must ensure that non-SSL connections are either denied or converted to SSL.

Managing Account Lockout

User Accounts are vulnerable to dictionary attacks or brute force attacks. These attacks are ones where user credentials are deduced through successive attempts. Using tools or scripts enable the attacker to automate the process and establish a positive match more quickly and efficiently.

The "Good Practices" would be:

1. Design usernames which are not predictable or guessable.
2. Strong password policy.
   
3. Disable user account after n failed login attempts which are successive.
4. You could also consider locking out account for a specified amount of time. For e.g. 30 mins.
5. Display generic error messages to user on failed login attempt. E.g. "Authentication Failed - Invalid Username / Invalid Password / Account Locked
6. No automatic account lockouts for admin accounts
   
7. Implement CAPTCHA's to prevent bots or automated username/password guessing.
   

Mitigating XSS Attacks in ASP.NET Apps

Most of the security analyst must be finding it difficult to completely eradicate chances of Cross Site Scripting Attacks. As far as Microsoft ASP.NET platform goes, it does provide a directive called ValidateRequest to check for input containing malicious code.

This directive was present since .NET 1.1 version. However, I find several cases where the application team deviates from having this directive set to true for some business reasons. For eg. there is a rich text box in the web page which must allow any kind of input data. If ValidateRequest is configured for this web page or for the application as a whole, it will throw HttpRequestValidationException before the input is even processed by your code.

So we started recommending that you must use output validation i.e HTMLEncode all data echoed back on web page. You could also use the new Microsoft Anti-XSS library.

In conclusion, ValidateRequest should be turned on if it does not block valid user scenarios. However, even with ValidateRequest turned on, it MUST not be regarded as a full proof solution to mitigate XSS.

Useful resources:
http://msdn2.microsoft.com/en-us/library/ms998274.aspx
http://msdn2.microsoft.com/en-us/library/system.web.httprequestvalidationexception(vs.80).aspx
http://msdn2.microsoft.com/en-us/library/ms998274.aspx

Cheers.

PCI DSS Applicability Information

* These data elements must be protected if stored in conjunction with the PAN. This protection must be consistent with PCI DSS requirements for general protection of the cardholder environment. Additionally, other legislation (for example, related to consumer personal data protection, privacy, identity theft, or data security) may require specific protection of this data, or proper disclosure of a company's practices if consumer-related personal data is being collected during the course of business. PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted.

** Sensitive authentication data must not be stored subsequent to authorization (even if encrypted).

SQL Injection in Stored Procedure : 2nd Case Study

Stored procedure with dynamic SQL and embedded parameters

The Stored Procedure

Create proc authenticate (@uid nvarchar(25),@pwd nvarchar(25))
as
DECLARE @uid VARCHAR(64)
DECLARE @pwd VARCHAR(64)
DECLARE @SQLString NVARCHAR(500)
DECLARE @ParmDefinition NVARCHAR(500)

/* Build the SQL string once.*/

SET @SQLString =
N'SELECT * FROM users WHERE userid = @uid AND password = @pwd'

SET @ParmDefinition = N'@login VARCHAR(64), @password VARCHAR(64)'


Server side code:

cmd.CommandText = "authenticate";
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.Add( "@uid", strUserName);
cmd.Paramerters.Add( “@pwd, strPassword);
con.Open();

string result = (string)cmd.ExecuteScalar();
oCon.Close();

In this case,bSQL Injection would NOT be possible. Hence what I would like to summarize is if at all we have to use dynamic SQL in stored procedure, always use embedded parameters in dynamic SQL

SQL Injection in Stored Procedure

Let us examine SQL Injection in Stored Procedure. This would be 1 of the vulnerable cases.

The Server Side Code would be something like:
oCmd.CommandText = "sp_login";
oCmd.CommandType = CommandType.StoredProcedure;
oCmd.Parameters.Add( "@loginId", strUserName);
oCmd.Paramerters.Add( “@password”, strPassword);
oCon.Open();
string result = (string)oCmd.ExecuteScalar();
oCon.Close();
====================================================================
The Stored Procedure would be:
CREATE PROC sp_login (@loginid nvarchar(25),@password)
AS
DECLARE @SQLString NVARCHAR(500)
DECLARE @loginid VARCHAR(64)
DECLARE @password VARCHAR(64)

/* Build the SQL string once.*/

SET @SQLString = 'SELECT * from cust_users WHERE login_id = '+ ''''+@loginid+'''' + 'AND password = '+ ''''+@password+''''

EXECUTE sp_executesql @SQLString

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

If the user input is as follows:
loginId = ' OR 1=1 --
password = junk

The above stored procedure will have an injection attack. The procedure executing will return all the rows because of the injected SQL.

Cheers.

Data Validation for App Security

Riding the Third Wave

HTTP Pipelines in ASP.NET

1. ASP.Net uses a pipeline model to process incoming requests and provide responses.
2. The steps in the pipeline are:

• HTTP Runtime
• HTTP Application Factory
• HTTP Application
• HTTP Handler Factory
• HTTP Handler

3. When IIS receives a request, it checks the extension of the requested page.
4. If the extension is .aspx, then it invokes aspnet_isapi.dll and passes the request to it
5. The aspnet_isapi.dll calls the HTTP Runtime object in the ASP .Net worker process
6. The pipeline is implemented inside this worker process (Aspnet_wp.exe)
7. The HTTP Runtime passes the request to the HTTP Application Factory
8. The Application Factory creates an application object for the request (or reuses an existing one) by looking at which application should be invoked
9. Every virtual folder is a different “application” to IIS
10. The HTTP Application objects contains modules or filters
a. The filters can be used inspect and modify HTTP requests and responses
b. For eg, to cloak the banner of the response, or filter out HTML or script tags in the request
c. Web application firewalls will be implemented as filters
d. The filters that are active for each app can be configured in web.config
11. The HTTP Application Object uses the Handler Factory to create the appropriate Handler to pass on the request
12. The HTTP Handler is the endpoint in the pipeline. It calls the .aspx page/assembly
13. The Handler has a method called “processRequest” that is called by the Application object
14. Custom handlers can be configured in web.config
15. An IIS web server will have only one asp.net worker process at a time
16. Each worker process contains multiple app domains
17. App domains are light weight processes running inside the worker process
18. App domains are .net “processes”, different from the Windows processes
19. Each application runs on different app domains.
20. These app domains enforce isolation.
21. When multiple requests are made to the IIS server, all of them are serviced by the same HTTP runtime and the same Application Factory.
22. The Application Factory creates new app domains to service concurrent requests

References:
a. Security and HTTP Pipelines in ASP.NET:
http://msdn.microsoft.com/msdnmag/issues/02/09/HTTPPipelines/default.aspx

Thick Client Application Security

This article discusses the top vulnerabilities in a two tier thick client application.

Thick client is defined as an applicationclient that processes data in addition to rendering. An example of thick client application would be a VB.NET or Java Swing application that communicates with a database.

I have generally observed in these types of applications have weak access controls, weak authentication management, information disclosure, improper error handling or application crash.

It is interesting to note that most of the Open Web Application Security Project (OWASP) Top 10 vulnerabilities are as applicable to Thick Client applications as they are to web applications.

Let us map them for simplicity.

Sr	OWASP Top 10 (Web Apps)	Thick Client
1	Unvalidated Input	Unvalidated Input
2	Broken Access Control	Broken Access Control
3	Broken Authentication & Session Management	Weak Authentication & Session Management
4	Cross-Site Scripting Flaws	Not Applicable
5	Buffer Overflows	Buffer Overflows
6	Injection Flaws	Injection Flaws
7	Improper Error Handling	Improper Error Handling
8	Insecure Storage	Insecure Storage
9	Denial of Service	Denial of Service
10	Insecure Configuration Management	Insecure Configuration Management

PCI Compliance bothering???

Hi,

When I was reading thru PCI DSS standards, something that was bothering me was the following requirement:

Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:

* Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
* Installing an application layer firewall in front of web-facing applications.

This method is to be considered a best practice until June 30, 2008, after which it becomes a
requirement.

My confusion was whether I had to hire someone to go a code review or penetration testing or would other means work ?? Finally I could clear this by posting it to PCI and getting the answer.

What they mentioned was :
-----------------------------------------------

Using specialized 3rd-party tools that perform thorough analysis of applications to detect vulnerabilities and defects may well meet the intention and objectives of the source code review requirement in PCI Data Security Standard requirement 6.6, if the company using the 3rd-party tool also has the internal expertise to understand the findings and make appropriate changes.

The PCI Security Standards Council will look to clarify this section of the standard during the next revision, to include that testing of web-facing applications can be done via source code review or products that test the application thoroughly for defects and vulnerabilities (when internal staff have the skills to use the tool and fix defects). The PCI Security Standards Council will also consider including prescriptive requirements as to what both the application firewall and application analysis tool or process should test for.

-----------------------------------------------

Finally, I could settle for the confusion. I need not go for a 3rd party review to go through several lines of code or do it myself. I can very well use tools like WebInspect and AMP to complete this requirement.

Cheers,
Dharmesh.

Westside in Mumbai stores your credit card numbers..

Hi,

If you are a Mumbai local, I am sure you would have visited Westside - one of the famous retail shops. I happened to bump into their store in Andheri(W) Infinity Mall and to my surprise, when I gave my credit card for swipe, they swiped it twice. :(
- Once on the processing machine and second on his computer.

I asked the fellow, "Why are u swiping my card twice?"

He replies, "Sir, we need to store your card information for tallying it at the end of day."
I was really disturbed by this. They stored my name, card number and expiry date. Only thing remaining was the CCV number. Remember this is generally a 3 or 4 digit number usually at the back of the card.

I am surprised that these merchants are allowed to store credit card information. No PCI compliance required ??

I felt like calling up the media - Mumbai Mirror, DNA or Times and yelling them that see these guys....what are they upto ?? Why the hell are they storing credit card information and if they need it, why is is not encrypted??

A hacker's mind would surely think of compromising their database having thousands and thousands of credit card holders information.

To add to all my fuss that day, they gave me a printed receipt to sign off and that too printed my entire credit card number (none of the digits were masked) and even the expiry date.

I am sure there are many such places in mumbai where credit card information is stored and is highly likely for hackers to get inside them very easily. If the merchants or shop owners do not bother to care about the credit card information, they must be banned from handling these transactions.

I wanted to raise my voice for all the people who actually opt for credit card transactions. Please make sure and shout if you find they are storing your credit card information. If they are swiping the card twice for their sake. This is illegal.

Visa / Mastercard and other card issuers must look into this matter asap.

Please send in your comments and let's raise this to get in media of possible and spread awareness.

Thanks.

Dharmesh.

Oracle Default Passwords

Hi,

Beware of database Default Accounts before you ship your database to production.
I saw this screen while installing Oracle. I think this kind of screen should be shown in all database tools and also there should be a warning mentioning the harm of keeping the default accounts ON in the database.

For now, enjoy this screen... :)

Introducing - TechTrails

Dear Software Professional ,

So the rupee’s rising. Now why’s that causing sleepless nights for some software exporters? And hey, what’s the net impact on you? . Does this rise of the rupee present a great opportunity that could have far-reaching positive consequences ? What is the future of Indian IT industry ? What will happen when other low cost destinations for outsourcing catch up with India ? Will India sustain it’s cost advantage ? These are questions that impact your career and you need an answer on how and what you need to do to get ready for the next wave of Indian IT .


www.techtrails.com has the answers for you .


This is the only web portal of it’s kind that will help you as a IT professional or a student planning a career in IT to get ready for the future . Thought leadership articles , interviews with industry leaders , tips and tricks , white papers www.techtrails.com has it all . Besides you would get invited to free seminars and panel discussions on topics that would impact you .

Over time the www.techtrails.com would be a place for 3rd wave Indian IT professionals to hang out , exchange information , share links to their blogs , upload content that would be of benefit to all who are a part of this community .


Registration to www.techtrails.com is Free ! Rush and register yourself to www.techtrails.com Now !

App Security Testing Cheat Sheet

Hi,

I thought to prepare a brief cheat sheet for Application Security Testing.

Please have a look and drop in your views. In case you wish to use it for your testing, please drop me a mail at dharmeshmm at gmail dot com to notify me about it.

Authentication Checks

1. Login and Change Password pages on SSL?
2. All sensitive pages (accepting SSN, Credit Card) over SSL?
3. Strong Password Policy? (Joe Accounts/Blank Passwords/Max Password Age/Min Password Age, etc)
4. Is Forgot Password page secure?
5. Password Change forced on 1st login?
6. Re-authenticate before moving to sensitive pages (Edit Account Info?)
7. Prompts old password before changing password?
8. Has "Remember Me" feature? If so, how's password stored?
9. Warns before allowing "Remember Me"?
10. Has CAPTCHA to prevent password guessing?
11. Does show error msgs like "Invalid User/Invalid Password"?
12. Can auth. be by-passed for priviledged URL's?
13. Is AutoComplete set to OFF?
14. Is password re-submitted on 'Back/Refresh' of browser?
15. SQL Injection in login?

Session Management

1. Is session id random enough?
2. Session Timeout present?
3. Stored in what form? (persistent cookie/in-memory cookie)?
4. Session Id expires on request tampering?
5. Sensitive data in cookie?
6. Can you see X user's data with Y's session id?
7. Session expires at server-side on logout?
8. Can logged out user's session be re-used?
9. Is new session id generated on login?
10. Is cookie over-written on logout?

SQL Injection Checks

1. SQL Injection : '
2. SQL Injection : ' OR 1=1 --
3. SQL Injection : '; waitfor delay'00:00:05'--

XSS Checks

1. XSS Javascript
2. XSS Encoded
3. XSS Cookie
4. Is CSRF possible?

Input Validation Checks

1. Use proxy to by-pass client side validation?
2. Generate errors for information disclosure?
3. Web Page source reveals sensitive application information
4. HTTP Headers manipulation
5. Viewstate manipulation
6. GET and POST parameter manipulation

Secure Storage Checks

1. Are passwords stored in clear text?
2. Is sensitive information like Credit Card encrypted?
3. What encryption algo used? Standard or Proprietary?
4. Is connection string in clear text?
5. Any passwords hard-coded in application?

Browser Checks
1. Check browser history? Are sensitive pages cached?
2. Is data cached by search engines or desktop search engine?
3. Any hard-coded secrets in javascripts?
4. Web Page code reveals sensitive comments?

File Checks

1. Is file upload /download allowed?
2. Can files be downloaded directly from URL?
3. Can malicious files be uploaded?


Environment Checks

1. Are default apps installed?
2. Are default accounts enabled? Do they have strong passwords?
3. Is firewall deployed?
4. Is code obfuscated?
5. Can detect server details using banner grabbing?
6. Are forms bot resistant?

In case you have your views, please feel free to write here or mail me at dharmeshmm at gmail dot com

Cheers,
Dharmesh.

Get into pay sites for free as a Googlebot

Ever wondered why Google returned search results that lead to sites that require a registration? How did Google index the site without a registration? Many sites want their site indexed in Google to receive more hits, so they allow Googlebots in. Because of this reason we can take advantage of this. All we have to do is disguise ourself as a Googlebot and many sites will let us in without registration.

To do this we have to change the User Agent. The user agent defines the browser and what version you are using. For example if you go to this site it will tell you what browser you are using, and it finds this info out by the user agent.

Changing the user agent is easy, to do this in Opera you have to uses these settings:

User Agent: Googlebot/2.1 Compatible: http://www.googlebot.com/bot.html

Firefox users can use this extension and import this file (right click and save) that has a huge list of user agent settings including Googlebot/2.1 and many other spiders/bots.

Internet Explorer users you will need to change the registry entries, to do this open notepad and copy this into it:

Windows Registry Editor Version 5.00 [HKEYLOCALMACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet Settings5.0User Agent] @="Googlebot/2.1" "Compatible"="+http://www.googlebot.com/bot.html"

Then save it as ua.reg and double click on it.

To revert the changes back, you will need to do the same but this time copy this in:

Windows Registry Editor Version 5.00 [HKEYLOCALMACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet Settings5.0User Agent] @="Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

Save as oua.reg and double click.

To see if it has worked go here and your browser should now be Googlebot v2.1

Enjoy!

The Perceptive Pixel

OWASP Mumbai Venue Map - 6th Sep Meet