Things to remember while developing web application (Some Practices)
See to it!!
Visual representation plays a big role in boosting customer involvement. The sooner customer is able to see the UI of the application, more he tends to get involved. The visual representation makes the customer come up with modifications sooner than later.
Involved evolvement
Customer should always be involved throughout the course of application development. Team should create the process to get the frequent feedbacks and directions. Lack of feedback should be taken up as a risk ASAP specially in case of extreme development with Agile.
See the point
Customers do need the complete application but are not willing to give time. It’s a known fact that application cannot be bug free. If get to understand the business aspect of the application, we can prioritize the testing effort on the specific modules. Modules exposed to probable clients of the customers are the most sensitive one. Specially if you are not providing the need based service.
Testable ability
Make your intermediate deliveries completely testable. This keeps the testers attitude in high spirits. In case a complete solution could not be available, try to provide testing scripts to validate the solution. Manual verification deviates the tester from the holistic view of the application.
Input Validation
Don't assume that your users will provide you with valid, trustworthy data. Sanitize all data, checking for sane string lengths, valid file types, etc.
Guidelines for User-Supplied Input
Character-set: Only accept data containing a strictly limited and expected set of characters. If a number is expected, only accept digits. If a word, only letters.
Data Format: Only accept data containing the proper format. If an email address is expected, only letters, numbers, at symbol, dashes, and dots in the proper arrangement should be accepted. This includes enforcing minimum and maximum length restrictions on all incoming data. The technique should be used for account numbers, session credentials, usernames, etc. This limits the potential entry points for incoming attacks.
Escaping: All special characters from incoming data should be escaped to remove an additional programmatic meaning.
Non-trusted data
Non-trusted data is most often data that comes from the HTTP request, in the form of URL parameters, form fields, headers, or cookies. Traditionally, input validation has been the preferred approach for handling non-trusted data. However, input validation is not a great solution for injection attacks.
Escaping
Escaping is a technique used to ensure that characters are treated as data, not as characters that are relevant to the interpreter's parser. There are lots of different types of escaping, sometimes confusingly called output "encoding”. Do not confuse output escaping with the notion of Unicode character encoding, which involves mapping a Unicode character to a sequence of bits. This level of encoding is automatically decoded, and does not defuse attacks. However, if there are misunderstandings about the intended char set between the server and browser, it may cause unintended characters to be communicated.
Escaping is the primary means to make sure that non-trusted data can't be used to convey an injection attack. There is no harm in escaping data properly - it will still render in the browser properly. Escaping simply lets the interpreter know that the data is not intended to be executed, and therefore prevents attacks from working.
Injection Theory
Injection is an attack that involves breaking out of a data context and switching into a code context through the use of special characters that are significant in the interpreter being used.
There are two ways to inject code:
Injecting UP
The most common way is to close the current context and start a new code context. For example, this is what you do when you close an HTML attribute with a "> and start a new tag may be able to terminate a script block even if it is injected inside a quoted string inside a method call inside the script. This happens because the HTML parser runs before the JavaScript parser.
Injecting DOWN
The less common way to perform XSS injection is to introduce a code sub context without closing the current context. For example, if the attacker is able to change into < src="javascript:alert(document.cookie)"> they do not have to break out of the HTML attribute context. Instead, they introduce a sub context that allows scripting within the src attribute (in this case a javascript URL).
Cross-Site Scripting (XSS)
XSS attacks are, by most measures, the most common form of security problem on the web. In short, if an attacker can get their own JavaScript code into your application, they can do bad stuff. Anywhere you store and display non-trusted, user-supplied data needs to be checked, sanitized, and HTML escaped. Getting this right is hard, because hackers have many different ways to land XSS attacks. Your language or web development framework probably has a popular, well-tested mechanism for defending against cross-site scripting; please make use of it.
Always escape HTML before inserting non-trusted data into html content. Escape characters with HTML entity encoding to prevent switching into any execution context.
Refer: http://code.google.com/p/owasp-esapi-java/
Broadly escaping is required in case of
- Attribute
- Javascript
- CSS or
- URL is modified with the user supplied data.
XSS attack ca be mitigated by using HttpOnly (refer: http://www.owasp.org/index.php/HTTPOnly)
In-Depth Protection
The fundamental concept is that there should be multiple layers of security protecting your assets. Layers of security include input validation, database layer abstraction, server configuration, etc. Once in place it is necessary to frequently test the security of those layers. The reasoning behind In-Depth is that if any layer is breached, there is another layer in place preventing compromise. With defense-in-depth, the risks associated with security lapses are significantly mitigated.
Rate Limiting
Be sure that users can't take advantage of your application by repeatedly performing resource-expensive or socially detrimental actions. For example, don't let users repeatedly attempt to login or reset passwords. Use CAPTCHAs where appropriate to slow down potential spammers and attackers.
Comments
Post a Comment