Contact us for your penetration testing needs 1-866-PLYNT-24    |   Contact Us   Plynt UK Website  
Click to get Security Testing Quote

I'm a developer

  1. What is SQL Injection?
  2. How do I prevent SQL Injection?
  3. I use stored procedures. Any chance I'm vulnerable to SQL Injection?
  4. I am using client side validation using Javascript for checking user inputs. Isn’t that enough?
  5. Is there some way to prevent these proxy tools from editing the content the user sends to the application?
  6. I notice that a lot of sensitive pages in my app are getting cached on the browser. How do I prevent that?
  7. I don't think anybody can exploit my application with the help of the error messages it displays or can they?
  8. My application allows users to upload files. What precautions should I take?
  9. My site will be used from publicly shared computers. What precautions must I take?
  10. All my web pages have SSL enabled. You still think I might be vulnerable to these attacks?
  11. Tell me again: what exactly are the benefits of SSL?
  12. We develop .Net/J2EE applications. Are there good secure coding guidelines I can share with my developers?
  13. I want to use the most secure language; which language do you recommend?
  14. Are there any training programs on secure programming that I can attend?
  15. Which are good books on application security for developers?
  16. Why are buffer overflows unlikely in web applications?
What is SQL Injection?

Here's how the OWASP FAQ introduces SQL Injection:

"SQL Injection is a technique by which attackers can execute SQL statements of their choice on the backend database by manipulating the input to the application.

Let's understand SQL Injection through the example of a login page in a web application where the database is SQL Server. The user needs to input Username and Password in the text boxes in Login.asp page. Suppose the user enters the following: Username: Obelix and Password: Dogmatix. This input is then used to build a query dynamically which would be something like: SELECT * FROM Users WHERE username= 'Obelix' and password='Dogmatix' This query would return to the application a row from the database with the given values. The user is considered authenticated if the database returns one or more rows to the application.

Now, suppose an attacker enters the following input in the login page: Username: ' or 1=1-- The query built will look like this: SELECT * FROM Users WHERE username= or 1=1-- and password= -- in SQL Server is used to comment out the rest of the line. So, our query is now effectively: SELECT * FROM Users WHERE username= or 1=1. This query will look in the database for a row where either username is blank or the condition 1=1 is met. Since the latter always evaluates to true, the query will return all rows of the Users table and the user is authenticated. The attacker has been successful in logging into the application without a username and password."

Integrigy's introductory article to SQL Injection is a great piece. So is Chris Anley's advanced paper on SQL Injection. Victor Chapela's presentation at OWASP explains many SQL Injection techniques.

How do I prevent SQL Injection?

There're several ways to prevent SQL Injection. One method is to validate each input, ensure that no special characters or SQL sub-strings enter your input. An attacker might still slip through that validation filter. A stronger approach is to avoid using dynamic SQL queries while querying the database. CallableStatements and PreparedStatements in Java, ADOCommand objects in ASP.Net all use pre-compiled queries that are safe from SQL Injection.

We discussed these techniques in this Palisade Quiz.

I use stored procedures. Any chance I'm vulnerable to SQL Injection?

The short answer is "yes".

SQL Injection is the result of using dynamic SQL statements, those that are created at run time from user inputs. Stored procedures are pre-compiled pieces of code, so one wouldn't expect them to be vulnerable to SQL Injection.

To quote Chris Anley's classic "Advanced SQL Injection" paper (page 17):
Traditional wisdom holds that if an ASP application uses stored procedures in the database, that SQL injection is not possible. This is a half-truth, and it depends on the manner in which the stored procedure is called from the ASP script.
Essentially, if a parameterised query is run, and the user-supplied parameters are passed safely to the query, then SQL injection is typically impossible. However, if the attacker can exert any influence over the non - data parts of the query string that is run, it is likely that they will be able to control the database.
Good general rules are:

  • If the ASP script creates a SQL query string that is submitted to the server, it is vulnerable to SQL injection, *even if* it uses stored procedures
  • If the ASP script uses a procedure object that wraps the assignment of parameters to a stored procedure (such as the ADO command object, used with the Parameters collection) then it is generally safe, though this depends on the object's implementation.
  • Santosh explained this in detail in the article Are stored procedures safe against SQL injection?

I am using client side validation using Javascript for checking user inputs. Isn’t that enough?

Client side validation for checking user inputs is a good thing to have as it speeds up user experience. However, relying only on client side validation would be a bad programming practice. There are a number of freely available tools called web proxy editors (E.g. Webscarab, Burpproxy) which allows users to intercept and edit the requests being sent to the server. These tools can be used to bypass all client side validations. Thus, it is essential to have input validation done at the server as well.

Is there some way to prevent these proxy tools from editing the content the user sends to the application?

According to the OWASP FAQ:

"The main threat these proxy tools pose is editing the information sent from the client to the server. One way to prevent it is to sign the message sent from the client with a Java Applet downloaded onto the client machine. Since the applet we developed will be the one validating the certificate and not the browser, a proxy tool will not be able to get in between the client and the server with a fake certificate. The applet will reject the fake certificate. The public key of this certificate can then be used to digitally sign each message sent between the client and the server. An attacker would then have to replace the embedded certificate in the applet with a fake certificate to succeed - that raises the barrier for the attacker."

I notice that a lot of sensitive pages in my app are getting cached on the browser. How do I prevent that?

In order to improve performance, browsers often cache web pages. All the cached web pages are automatically stored in the Temporary Internet files on the local PC. An adversary is able to access these files by just clicking any link from the history of the browser or else clicking on the link in the temporary Internet files folder. Web pages can be prevented from getting cached by issuing the correct cache control headers in the server response. The cache control directives can be set from the code and these prevent caching of the web pages on the browser. The directives to be set are:

cache-control: no-cache

or

cache-control: no-store

A great resource to learn about caching is Mark Nottingham's paper on caching.

I don't think anybody can exploit my application with the help of the error messages it displays or can they?

Error messages can give out a whole lot of information about the application.

Sometimes during the design and development stages we miss out on customizing the error messages. The application may give out information about the architecture or the business details etc. All such information helps an adversary plan further attacks.

One common issue I've seen is getting details about the database on entering unexpected inputs. Let's see how this is possible: consider an application uses Oracle as the backend database and does not handle errors properly. An adversary enters some unexpected input in a form field and sends the request to the server. The sever sends back a error message which says "Error parsing and updating transaction request -ORA-20000". This clearly tells the adversary that Oracle is being used at the backend and now he can carry refine his attacks based on this information.

As a best practice, no architectural details should be disclosed to the user.

This article explains how to turn off error messages safely.

Chris Anley's advanced SQL Injection paper explains how to use error messages to fine-tune a SQL Injection attack.

My application allows users to upload files. What precautions should I take?

File uploads can be a risk, if files are uploaded to a directory that has execute/script permissions. Then, an adversary can upload a malicious script or executable. When that gets executed (by invoking it remotely, say), it can cause damage.

Here're two precautions to take:

- Store the files in a private space that's not accessible to a
user directly from the web. For eg, store the files in a database.

- If the files are stored in the file system, then do not give write or execute permissions in that folder.

My site will be used from publicly shared computers. What precautions must I take?

To quote the OWASP FAQ:

- You can make sure your pages do not get cached on the system by setting
the correct cache control directives.

- You could take care that no sensitive information is included in the URLs
since the history of the client browser will store these.

- Have a graphical keyboard for entering the password or ask the user to enter
a different part of the password each time. This protects the password
against keystroke loggers.

- To prevent sniffing of passwords and replay attacks using those, you should
either use SSL or salted MD5 for passwords. The clear text password in the
memory should be reset after computing the MD5.

All my web pages have SSL enabled. You still think I might be vulnerable to these attacks?

A common misconception is that SSL is the answer to most attacks.

SSL ensures that the server is who he claims to be, and that the traffic cannot be eavesdropped by anybody else. It achieves this by using a digital certificate to prove the authenticty of the server, and encryption to secure the traffic.

However, SSL cannot prevent an adversary intercepting his own communication with server using freely available web proxy editor tools (e.g. Webscarab, Burpproxy etc.). These tools intercept SSL communication within the adversary’s machine and present editable data to him in plaintext, which can be used to launch several popular attacks.

Tell me again: what exactly are the benefits of SSL?

Secure Sockets Layer or SSL for short provides the following benefits:

Authentication of the server

Whenever an end user connects to an SSL enabled site, the Server sends its unique Digital certificate which is approved and signed from a universally trusted source (E.g. Verisign). This guarantees an end user that he is communicating with the right server.

Communication privacy

SSL uses public key as well as private key encryption technologies to provide an encrypted channel. This channel ensures an end user that all communication between the user’s browser and the Webserver remains encrypted. Thus, any one intercepting or sniffing the communication will only see garbled text which would make no sense.

We develop .Net/J2EE applications. Are there good secure coding guidelines I can share with my developers?

Plynt has published a Secure Coding Guidelines Tutorial for .Net and this is available at Plynt

Microsoft has released a 147-page guide to secure .Net programming. Lots of goodies in that, including checklists etc. It is available at the URL.

Some more sites which you can check out are Secure Coding for Java ,
OWASP.

I want to use the most secure language; which language do you recommend?

To quote the OWASP FAQ "Any language can be used since secure programming practices are what make applications safe. Most security techniques can be implemented in any language. Our advice would be to use any language you are comfortable with. But some languages like Java have additional features like bind variables that aid security; you could use those additional features if you decide to program in that language."

Are there any training programs on secure programming that I can attend?

Microsoft offers training programs on Developing Security-Enhanced Web Applications and Developing and Deploying Secure Microsoft .NET Framework Application. More information can be found at 2300AFinal and 2350BFinal
Aspect Security offers a similar course.
Paladion Networks offers Application Security training for J2EE developers. More details available at Paladion

Which are good books on application security for developers?

Here're some of the good books for developers:

Why are buffer overflows unlikely in web applications?

There are two reasons why we don't see buffer overflows in web applications.

First, to discover a buffer overflow, an attacker has to either get access to the source code, or get local access to the system on which the application is running. It's by checking the app's response to long inputs and tracing the execution that an attacker learns if it's vulnerable. Web apps are usually attacked remotely and the adversaries rarely see the source code. It then becomes very difficult to discover a buffer overflow in a web app.

Secondly, to perform a buffer overflow, the compiler should let data be stored into memory that has not been properly allocated. Languages like Java do not support that (unlike C, C++). So it's impossible to do buffer overflows in Java apps anyway. FAQS.org explains this well here.

On a cautionary note, there have been instances of PHP library functions (written in C themselves) being vulnerable to buffer overflows. Here're two examples [1, 2]. So open source PHP web apps need to take special care against buffer overflows when they call unsafe functions.

Jeremiah Grossman wrote a lucid article de-bunking buffer overflows in web applications: Myth-Busting Web Application Buffer Overflows Do check that out.


Request a proposal

Our quote contains the best price, the time estimate, and our methodology; and we'll mail you the quote in 24 hrs.


                                                
 
Movable Type Appliance - Powered by TurnKey Linux