Simple Autocomplete

IRCTC - India's Rail Ticket Booking Website which is sought to be a secure platform for the citizens booking their tickets has few simple security configurations missing.

An example is the auto-complete not set to off on their payments page - a practice which most of the secure web applications follow for sensitive pages right from login page. Below is a snapshot.

Isn't that Impossible?

Not every organization and their people know about software security issues nor do they respect the same.

In most of my workshops conducted with developers for secure coding, I often hear the proclamation, "Isn't that Impossible..." and then the drama starts...

Many developers do not understand how the web works
• “Users can’t change the value of a drop down”
• “That option is greyed out”
• “We don’t even link to that page”

Many developers doubts attacker motivation
• “You are using specialized tools; our users don’t use those”
• “Why would anyone put a string that long into that field?”
• “It’s just an internal application” (in an enterprise with 80k employees and a flat network)
• “This application has a small user community; we know who is authenticated to it” (huh?)
• “You have been doing this a long time, nobody else would be able to find that in a reasonable time frame!”

Many developers do not understand the difference between network and application security
• “That application is behind 3 firewalls!”
• “We’re using SSL”
• “That system isn’t even exposed to the outside”

Many developers do not understand a vulnerability class
• “That’s just an error message” (usually related to SQL Injection)
• “You can’t even fit a valid SQL statement in 10 characters”

Many developers cite incorrect or inadequate architectural mitigations
• “You can’t execute code from the stack, it is read-only on all Intel processors”
• “Our WAF protects against XSS attacks” (well, clearly it didn’t protect against the one I’m showing you)
Developer cites questionable tradeoffs
• “Calculating a hash value will be far too expensive” (meanwhile, they’re issuing dozens of Ajax requests every time a user click a link)

There would be dozens more. The point that is developer education for security is one of the largest gaps in most SDLCs. How can you expect your developers to write secure code when you don’t teach them this stuff? You can only treat the symptoms for so long; eventually you have to attack the root cause.

Looking for better solution(s)

It's been 5 years that I have been looking over Application Security issues. It makes me wonder when I find myself and many others still looking out for some unsolved or better security solutions. Certain issues where we have broken our heads to get a solution, but at the end it hasn't been "enough" secure.

I thought it might be interesting to post my list of such issues for others to see things and get opinions on the same.

Still Looking for better (Secure) solutions for following points:
1. Implementing a strong Key Management solution for PCI Compliance. Customers trust products which can help achieve this compliance, however do not trust the bespoke implementation. I strive to get this done !!

2. Develop a better CAPTCHA mechanism to defend robots. A believe a real world user hates the current image version displayed. It has to be simple and secure.

3. Get the NAT'ed IP address of the user using HTML or Javascript.

4. Strong solution to prevent users from getting on to fake sites (Phishing) without much of user education.

5. Developing an Effective and Manageable Web Application Firewall which can be at least a bronze bullet (if not a silver bullet) for Web Security. :)

6. Designing security for social networking sites where a feature could be exploited to be a flaw.

Does the code use MapPath?

Review code for the use of MapPath. MapPath should be used to map the virtual path in the requested URL to a physical path on the server to ensure that cross-application mapping is not allowed.

The application should not contain code similar to the following example.

string mappedPath = Request.MapPath( inputPath.Text, Request.ApplicationPath);

Instead, the application should contain code similar to the following.

try
{

string mappedPath = Request.MapPath( inputPath.Text, Request.ApplicationPath, false);
}

catch (HttpException)
{
// Cross application mapping attempted.
}

Do You Use the HttpChannel?

If you use the HttpChannel for .NET remoting, you should prefer IIS as the host for the remote component because the component is loaded in the ASP.NET worker process. The ASP.NET worker process loads the server garbage collector, which is more efficient for garbage collection on multiprocessor machines. If you use a custom host, such as a Windows service, you can use only the workstation garbage collector. The HttpChannel also enables you to load balance components hosted in IIS.

Enabling SSL in IIS

How to Configure Certificates to Enable SSL in IIS?

Use SSL in IIS to protect the communication channel between your WCF enabled web application and the web client. SSL protects sensitive data on the network from being stolen or modified.

The following are the steps to configure certificates for Secure Sockets Layer (SSL) communication in IIS.

1. Click Start and then click Run.
2. In the Run dialog box, type inetmgr and then click OK.
3. In the Internet Information Services (IIS) Manager dialog box, expand the (local computer) node, and then expand the Web Sites node.
4. Right-click Default Web Site and then click Properties.
5. In the Default Web Site Properties dialog box, click the Directory Security tab, and then in the Secure Communications section, click Server Certificate.
6. On the Welcome screen of the Web Server Certificate Wizard, click Next to continue.
7. On the Server Certificate screen, select the Assign an existing certificate radio button option, and then click Next.
8. On the Available Certificates screen, select the certificate you created and installed in previous step, and then click Next.
9. Verify the information on the certificate summary screen, and then click Next.
10. Click Finish to complete the certificate installation.
11. In the Default Web Site Properties dialog box, click OK.

Polymorphic Exploitation

The emerging attacks by attackers which is dynamically changing each time a potential victim visits the malicious page is defying the traditional regular-expression and heuristic-based protection that identifies Web exploits at the network or host.

The attacker are very effective in creating a unique exploit with each request and making it impossible for signature-based protection engines to uniquely detect each attack instance.

The major driving factor for the attacker still remains Financial gain. Stealing personal data, hijacking Web transactions, executing phishing scams and perpetrating corporate espionage
are all motivators.

Traditional security techniques focus on stopping file execution and viruses at the client’s operating system (OS) layer. Unfortunately, it is far more difficult to protect users at the browser level. While some signature-based protection is able to detect one layer of Web exploit obfuscation, polymorphic exploitation will pose a new problem.

Proposed countermeasures for Web 2.0 and client side attacks include:
• Educating Web developers on the need for secure coding throughout the development lifecycle, with emphasis on input validation.
• Transitioning from finger-print or pattern matching protection to heuristics or behavior-based protection.
• Enabling protection engines to understand JavaScript just as the browser does.
• Utilizing feedback networks to analyze malicious Web sites, encourage remediation and improve content filtering at the browser level.

OWASP Summer of Code 2008

OWASP is now launching the Summer of Code 2008 (SoC 2008)

• The SoC 2008 is an open sponsorship program were participants/developers are paid to work on OWASP (and web security) related projects.
• The SoC 2008 is also an opportunity for external individual or company sponsors to challenge the participants/developers to work in areas in which they are willing to invest additional funding.
• The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. The mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks.
• The only requirement is that the candidate shows the potential to accomplish the project's objectives/deliveries and the commitment to dedicate the time required to complete it in the appropriate period.

More Details

Hacking Web Applications – Truly Simple

Application Hacking is the trend of the industry. It started with viruses and worms – The age of anti-virus. It evolved with the internet as more corporations developed internal and external networks – The age of Network Security. Now as industry has been powered with World Wide Web, information security has reached its third age – The age of Application Security. Application attack is one of the hardest attacks to recognize and defend against, as it uses your programs and systems against you.

If we recall the attacks few years back, we see that most of the organizations including NASA, CIA and Yahoo were attacked. These attacks were mostly at network layer of the corporate systems. The network layer is now very secure and hackers find it difficult if not impossible to attack at the network layer. Today, applications are the target. Attackers steal credit card numbers from bank site and an intruder breaks into a corporate application stealing sensitive employee information. Hackers use the application sitting behind the strong firewall and use a loop hole in the application to access corporate and customer data. As the industry embraces the benefits of e-business, the use of Web based technologies will continue to grow. However, as these technologies evolve, the vulnerabilities are being discovered at a similar rate. Secure implementation of these technologies cannot be achieved without a consistent approach to Web Application Security. Also the convergence of regulatory demands for application security with an increasingly security-savvy software buyer is driving a serious impetus for change.

Whether a security breach is made public or confined internally, the fact that a hacker has broken into your online assets should be a huge concern to organizations. Quite a large number of organizations are reactive to security incidents, pretending that the problem will go away. They respond with short-term fixes and the problems re-emerge rapidly. They fail to recognize the value of information and company reputation as opposed to cost of addressing security vulnerabilities.

Unlike certain worms and viruses that exploit the network security weaknesses, web application attacks go after flaws in the application itself. For example, an attacker could tamper with a part of HTTP request and use buffer overflows to corrupt an application by having it execute arbitrary code. In this way, an attacker could take control of the web or application server.

Ahh! We have a very strong password policy. But are passwords sufficient? Passwords are only as trustworthy as the people using them. If you rely on passwords to protect your online assets, then you are relying entirely on the people logging in and out. Let’s just draw a real world example. With popularity of social networking sites like www.orkut.com, we find thousands of people listing down their organization name and their work profile in public. What’s more concerning is they also list their family members with information of names and ages of their children. There is very high probability that a hacker may be able to find out a person’s password from the above information and get inside the organization’s defenses very quickly. Passwords are not sufficient to provide security to your online applications.

Does your firewall protect online assets? The traditional function of a firewall is to regulate the ports and services running on the server. Web applications by and large use port 80; and the firewall keeps this port open. This is the gold spot for the attackers. The beauty of application attack lies in sneaking through your firewall and use the application itself to break it. Firewalls cannot protect you from this happening.

With hacking tools being readily available and the complexity of attacking decreasing, it is relatively easy to find flaws in an application. A hacker could easily change the hidden fields of an online shopping site indicating price and smartly walk away without paying money. This is largely because while building applications, some of the most basic security measures, to keep information secure, were ignored. The cost of poor application security can be far greater than most organizations can imagine.

Organizations must take a proactive approach in protecting their critical web applications. The need lies in understanding how important application security is in the software development cycle. Application security must align as early as during requirement gathering, making way in secure design, development and deployment.

We are witnessing the emergence of more security-savvy buyer of software asking questions about the security practices and those are having a big impact on purchase decision. In long run, these companies will surely enjoy a higher return on investment.

Guarding Against Credit Card Frauds

The percentage of people using plastic money (cards) for transactions is growing day by day and so are the card scams rising along. We often hear or read about credit card frauds in our daily and how people end up in nightmares seeing huge bills for things they actually have never purchased. Likewise even the credit card companies are paying off handsome amount from their profit share to cover these fraudulent transactions.

Let me bring up few ways in which these frauds happen. By and large for physical credit card transactions, the deception story starts when the person who takes your card for swipe copies your card information to some other device. Later these details are copied to fake cards which are genuine card look alike with complete hologram markings and logos. The poor card holder remains completely unaware that his card has been cloned until he notices bill amounts of things he has never purchased. One of the other common methods is making a hoax call (often representing as card issuer authority) to the card holder and trying to retrieve card details. Credit card bills lying in trash cans or public places are other avenues where fraud originates.

Regarding users using cards for online transactions, one can see a large number of ways in which card data can be compromised. Falling in prey of a nice email asking for card details in return of discounts, or emailing card details to a friend or being a victim of card details being copied by an illegal software installed in cyber cafes are most common lines of attack sources.

One of the reasons in increasing successful frauds is inadequate knowledge of the card owner on proper use of credit cards. Here’s how credit card owners can better safeguard from these frauds.
• Over a credit card transaction, keep an eye on your card as it is being swiped. Make sure it is being swiped only once for a single successful transaction and get back your card as quickly as possible.
• Sign your credit card as soon as you receive it.
• Be protective of your credit card number so that others around you can't copy it or capture it on a cell phone or camera.
• Be prompt in keeping a check on your credit card bills to verify there are no bogus charges. For any charges that you don’t recognize, report these charges promptly to the card issuer.
• For people using cards at hotels or restaurants, remember to draw a line through blank portions of the receipt where additional charges could be fraudulently added other than hotel tips.
• In case of change of your billing address, notify your credit card issuers in advance so that bills reach safe hands.
• Save your receipts so you can compare them with your monthly bills.
• Always give your phone number to the company for verification of suspicious transactions.
• Be wary of any phone call or email seeking details of your account.
• Never give away photocopies of both sides of your credit card for any purpose.
• For online transactions, using credit card, remember to go by HTTPS and not HTTP.
• Avoid having e-transactions in a publicly share machine like Internet café or open free wireless network.

Online Banking Security

Banks today are increasingly getting introduced to a number of security threats. The ones in headlines have been Phishing, Key Logging and Man-in-the-Middle. We will find a number of online banking users who are naïve to this kind of technology and the threats associated with it. It is necessary to help them understand the precautions they must take to prevent being a victim of online theft.

Consumer education becomes a key element to prevent the manifestation of a number of risks into frauds. It is much easier for the experienced eyes of an internet-savvy user to detect potential phishing attempts when compared with a customer who has recently migrated from old school of banking to more recent modes.

On a happy note, there are solutions in the market to tackle problems of phishing, key loggers and man-in-the-middle attacks. But these are expensive solutions and not full proof.

Business Security Buy-In: Given the customer base or other reasons, it has not been easy for the banks to justify investing in secure solutions for online banking. In fact, many banks are willing to compensate for the fraud losses of the customers as they find it more cost effective than putting up a secure solution.

Security Challenges: Banks have to continuously evaluate the risks, cost of technology solutions and even upgradations. .It gets all the more challenging due to a variety of technological solutions available in the market, each addressing individual problems but none offering a one-stop solution.

Google Hacking

Web Hacking : Select a site, find a vulnerability
Google Hacking : Select a vulnerability, find a site :)

Some trials:

1. Advanced Operator : filetype

Search for filetype:mdb with keywords as users, passwords, credit, etc. View funny results.

2. Advanced Operator : allinurl
Cross-Site Frame Vulnerability allinurl: "url=http" "frame"

3. Directory Traversal Vulnerability
filetype: pl inurl:cg-bin inurl: file inurl:html

4. Spam Engines
filetype: cgi send mail

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.

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

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

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.

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... :)

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.