The importance of application security stems from the fact that there are so many risks associated with applications (threats, vulnerabilities) that organizations face nowadays. We realize that applications, whether web-based, client/server or mainframe, can have security risks and flaws. So what is application security?
Application security is a way to ensure that the applications that we develop in-house or buy off-the-shelf adhere to and enforce the security requirements needed to make the application function in a secure manner and free from flaws that could be exploited.
This can mean eliminating or mitigating risks by methods such as implementing strategies designed to minimize security flaws like exploitable bugs. It can also mean taking on strategies designed to meet particular goals, such as encrypting stored or transferred data, or ensuring that data sent between components of the application is authenticated and free from unauthorized modifications.
To satisfy application security goals, there are a number of approaches that we can use. The most important is integrating security in the development process; that is, integrating security in the design and requirements definition phase, in the detailed design and implementation (coding) phase, and in the quality assurance (QA) and testing process. Finally, after completion, security goals should be maintained during the lifecycle of the application.
Manual and automated approaches such as application vulnerability testing and/or penetration testing attempt to scan the application and identify vulnerabilities so that they can be fixed. Peer reviews and code analysis, done either with automated tools or by developers trained to find common logic/programming errors and which attempt to parse the code looking for mistakes/errors, are added important measures.
In addition to this, there are educational programs targeted at developers and implementers to make them aware of coding errors, security issues and vulnerabilities so that the applications they write are designed and written with security in mind.
The following have been identified by The SANS (SysAdmin, Audit, Network, Security) Institute and The Open Web Application Security Project (OWASP) as some of the most common vulnerabilities being exploited with web applications. They are offered here for reference and awareness to developers and application owners.
Cross Site Scripting (also abbreviated XSS) flaws happen when an application sends data from the client to a web browser without first validating or encoding the content. This lets hackers execute malicious scripts in a browser, letting them hijack user sessions, deface web sites, insert hostile content and conduct phishing attacks.
"Injection flaws allow attackers to create, read, update, or delete any arbitrary data available to the application," OWASP writes. "In the worst-case scenario, these flaws allow an attacker to completely compromise the application and the underlying systems even bypassing firewalls.
Avoid using interpreters if possible. "If you must invoke an interpreter, the key method to avoid injections is the use of safe APIs, such as strongly typed parameterized queries and object relational mapping libraries," OWASP writes. I would also suggest the use of stored procedures which execute already designed parameters.
Hackers can perform remote code execution, remote installation of rootkits, or completely compromise a system. Any type of Web application is vulnerable if it accepts filenames or files from users. The vulnerability may be most common with PHP Web development language.
Don't use input supplied by users in any filename for server-based resources, such as images and script inclusions. The intrusion prevention system rules can be used in addition to application URL parameter validation rules.
Attackers manipulate direct object references to gain unauthorized access to other objects. It happens when URLs or form parameters contain references to objects such as files, directories, database records or keys.
"References to database keys are frequently exposed," OWASP writes. "An attacker can attack these parameters simply by guessing or searching for another valid key.
Use an index, indirect reference map or another indirect method to avoid exposure of direct object references. If you can't avoid direct references, authenticate and authorize Web site visitors before using them. Also allow all components of the applications to use authentication. Example is using Java Authentication and Authorization Service in Java language container security.
This attack takes control of victim's browser when it is logged onto a Web site, and sends unauthorized malicious requests using the same session parameters to the Web application. Web sites are vulnerable because they tend to authorize requests based on session cookies without and no short TTL or "remember me" functionality.
"Ninety-nine percent of the applications on the Internet are susceptible to cross site request forgery," Williams says.
Don't rely on credentials or tokens automatically submitted by browsers. "The only solution is to use a custom token that the browser will not 'remember,'" OWASP writes.
Error messages that applications generate and display to users are useful to hackers and expose configuration details, URL mappings, database table names in some instances and internal workings of the system and application.
"Web applications will often leak information about their internal state through detailed or debug error messages. Often, this information can be leveraged to launch or even automate more powerful attacks," OWASP says.
Always do security testing as part and parcel of your application development QA methodology. Use a testing tool such as webinpect or appscan or OWASP'S WebScarab Project to discover vulnerabilities in your application and code.
User and administrative accounts can be hijacked when applications fail to protect credentials and session tokens from beginning to end.
"Flaws in the main authentication mechanism are not uncommon, but weaknesses are more often introduced through ancillary authentication functions such as logout, password management, timeout, remember me, secret question and account update," OWASP writes.
Communication and credential storage has to be secure in transfer and storage. The SSL protocol for transmitting over HTTP confidential and personal data and documents should be the only option for authenticated parts of the application, and credentials should be stored in hashed or encrypted form. Another recommendation is to get rid of custom cookies used for authentication or session management.
Many Web developers fail to encrypt the cryptographic keys used for data storage, even though cryptography is a key in most Web applications. When encryption is used, it's often poorly designed, using inappropriate ciphers and misunderstood to be complex and undoable.
"These flaws can lead to disclosure of sensitive data and compliance violations," OWASP writes.
Don't invent your own cryptographic algorithms or use open source weak and uncertified ciphers. "Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing," OWASP advises.
Furthermore, generate keys offline and share on a strict need to know basis, and never transmit or send private keys over insecure channels (in the clear) like FTP. Always store the private keys securely in directories protected from view and access control on a strict need to know basis.
Not encrypting network traffic in two areas. One between the client and the application and between the servers communicating personal and confidential information and application components. It is important to protect all sensitive communications like credentials, usernames and passwords and session IDs and private keys, etc.
Attackers can intercept and access unprotected conversations, including transmissions of credentials and sensitive information. For this reason, security standards like PCI (Payment Card Industry) standards require encryption of credit card information transmitted over the Internet and within the application and server components on the network.
How to protect: Use SSL 128bit minimum on any authenticated connection and/or during the transmission of sensitive data, such as user credentials, credit card details, health records and other private information. Use transport layer security or protocol level encryption like IPSEC with ESP (not AH) to protect communications between parts of your infrastructure, such as Web servers and database systems.
Some web pages and directories are supposed to be restricted to privileged users or different roles authorized by the application. Yet often the implementation is lacking what is needed to protect these pages, and hackers can find the URLs by making guesses or by using a script to manipulate URL input.
The attacks targeting this vulnerability are called forced browsing, "which encompasses guessing links and brute force techniques to find unprotected pages," OWASP says.
Protect all hidden URLs. All URLs should be protected by an effective access control mechanism that verifies the user's role and privileges and does not accept invalid input in the URL. "Make sure this is done . every step of the way, not just once towards the beginning of any multi-step process,' OWASP advises. I would also add to make sure that authorization and URL validation is taken into consideration. It always pays off to do security checks on the URLs in your QA process.
Please contact the Information Systems Security Manager.