sharing data: jsp security, authentication and integrity

8/3/2019 Sharing Data: JSP Security, Authentication and Integrity

1/17

Sharing Data: JSP Security,

Authentication and Integrity

Objectives:

Demonstrate sharing of data across pages Use URL rewriting to pass data Be familiar on how user authentication is implemented Give a thorough background on security guidelines

Concepts

In writing JSP pages, you often need to authenticate users and maintain some sort of control

over pages and flow. These restrictions help prevent users from making mistakes and keep the

JavaServer Engine running lean and efficiently, allocating space only for whats needed.

Although you wont often be in charge of security measures, youre still on the front line,

representing and enforcing security with users and every page of your applications. Additionally,

because enterprise systems grow dynamically and JSP scales well, you need to be aware of the potential

security risks as you move your designs from prototype to perfection.

Sharing Data

An essential part of any web application is the ability to share data across pages. Users must be

authenticated and identified, for security as well as for the allocation of server resources. If the data issensitive, it must be secured.

Using Hidden Fields to Pass Data

In the early of server-side programming and still quite frequently developers often passed

values from page to page by writing them into the hidden fields of a form of a dynamically generated

page.

BogusOrderSetup.jsp

.items, .selections {border-bottom:thin;border-bottom-style:solid;border-bottom-color:#999;

}


2/17

Bogus Order Setup

Please select what you want

Dictionary

Coffee Cake

Coffee


3/17

The page shown (BogusOrderSetup.jsp)

simply allows user to select several

items and place them in a shopping

cart.

BogusOrderCalculate.jsp

Bogus Order Calculate

Bogus Order Calculate


4/17

You ordered these item(s):

A Book
some Food

a Drink

The BogusOrderCalculate.jsp reads

the parameters pushed over by an

HTTP POST. The current order

items are displayed for users and

they can then complete the order.

If youll notice the code, you can

see the developer is storing price

values in hidden HTML field.

Ideally, users should never have

any access to variable values that

could directly affect the output.


5/17

FinalizeOrder.jsp

Finalize Order

Finalize Order

Your order totals:

a Book for:

Food for:

a Drink for:


6/17

WARNING: Nobody should use hidden fields

to pass sensitive data form one page to

another. Passwords, credit card numbers,

prices, running totals and so on all belong

elsewhere. Web pages that contain this

information can be unknowingly saved and

viewed offline, exposing a users privacy.

Worse yet, hackers can obtain and modify a

copy of the page to cause damage to a

customers account, a website or an

application.

Passing Data with URL Rewriting

In the previous examples, you observed how to pass parameters using HTTP GET and POST

requests and saw how to rewrite the URL and forward new parameters using the tag.

URL rewriting can be an alluring approach for developers since unlike POST page, the URL

appears in the browsers address bar where it can be copied, pasted, manipulated and re-pasted back

into the browser. This approach can be ok for development and it can be quite easy to even change a

servlets code so that the doGet method re-routes the request parameters to the doPost method. Of

course, you should change this and avoid it in production for several reasons.

Sensitive information can be accidentally be displayed in the browsers Address bar, wheresomebody could see it

Some applications and environments have limits on the length of Query String that could causeintermittent errors that are extremely difficult to debug.

Long Query String can be difficult to manage Perhaps worst of all, information submitted in a URL is most often written to web server logs.

Personal and sensitive information must be secured whenever possible, because a security chain

is only as strong as its weakest link.

Saving and Retrieving Session Information

In the previous examples, you have seen how a JavaBean can hold session information, but it is

helpful to see the mechanics behind the action. Additionally, in many cases customized processing must

handle requests in a manner beyond the default session-handling behavior of a JavaBean.


7/17

HappyTimesMenu.jsp

Happy Times Menu

.headings {background-color:#333;

}.labels {

font-family:Arial, Helvetica, sans-serif;font-size:16px;color:#CCC;

}

Happy Times Menu

Please select what you want.

Comics

Pistachios

Soda


8/17

HappyTimesMunchies.jspHappy Times Munchies

.headings {background-color:#333;

}.labels {

font-family:Arial, Helvetica, sans-serif;font-size:16px;color:#CCC;

}

a:link, a:active, a:visited {text-decoration:none;color:#666;font-family:Arial, Helvetica, sans-serif;


9/17

font-size:9px;}a:hover {

color:#F00;font-size:12px;font-weight:bolder;

}

Happy Times Menu

Please select what you want.

SalvadorDali
Coffee Table Book

Brownies

Cactus

Smoothie

Back |Happy Times Menu |More Orders |Hyperlink Submit


10/17

Tip: A submit action doesnt

always have to be triggered by a

submit button; Javascript attached

to a hyperlink can just as easily

accomplish the same effect.

For example:

A radio button can trigger a

submit:

MoreOrders.jsp

More Orders

More Orders

This page could hold more orders, or it could finalize an order.
Your previous selections are still stored in the session area.

Back To Menu
Back To Munchies


11/17

Handling Authentication (Application-Controlled Authentication)

A solution for a more dynamic user authentication mechanism controlled by a database and an

application. Most JSP applications demand that the authentication system be easy to use so the new

users can be added easily.A users session is the ideal place to ground an authentication scheme. Its

the proper place to set timeouts on pages and to check and make sure that each page being requested

is linked to a previously validated session.

UserAuth.java

package webbeans;

public class UserAuth {protected String username;

protected String password;protected boolean validUser = false;protected boolean isValidated = false;

public UserAuth(){}

//get and set Properties

public void setValidUser(boolean bBool){validUser = bBool;


12/17

}

public String getUsername(){return username;

}

public String getPassword(){return password;

}

public void setUsername(String newUsername){username = newUsername;

}

public void setPassword(String newPassword){password = newPassword;

}

public boolean isValidUser(){if(!isValidated || !validUser){

validateLogin();}validateLogin();return validUser;

}

public boolean getValidUser(){return validUser;

}

public void validateLogin(){if(username == null || password == null) {

validUser = false;return;

}if( username.equals((String)"prog313") &&

password.equals((String)"opensesame") ){isValidated = true;validUser = true;

}else {

validUser = false;isValidated = false;

}return;

}}

Note: The testing of the username and password should occur only once per session and the result

should be cached for each succeeding page to check. This helps minimize the traffic between the

JavaServer Engine and database.


13/17

UserAuth.jsp

.labels {

font:Arial, Helvetica, sans-serif;font-size:12px;}

User Authentication

User Authentication

Enter UserName:


14/17

out.print(cAr[ii].getValue());break;

}}

}

%>" name="username" />

Enter Password:

Save username a a cookie.

UserAuth.jsp used UserAuth JavaBean. The

JSP file also contains code for saving and

retrieving the users login name a persistent

cookie.

The user authentication page has a lot going

on. It reloads itself and reads the parameters

it sends to itself (username, password,

saveCookie). If prompted, it saves the

username the username as a cookie and then

it calls the UserAuthBean to check the users

credentials. If everything is ok, the user is forwarded onto a menu page that starts what could be a large,

complex, secured application.

SecurityHeader.jsp


15/17

Once the user is authenticated, they are forwarded to the page, SecuredApplication2.jsp.All subsequent

pages are built by including a SecurityHeader JSP that performs a check to make sure the user has

been properly authenticated.

SecuredApplication2.jsp

Secured Application

Secured Application Two This page cannot be seen without first loggin in.

A link to another secure page:
Page 1

Notice that the URL in the Address bar is

different from the browsers page

content (it says its the

SecureApplication JSP but in fact its

UserAuth JSP)

SecuredApplication.jsp

Secured Application


16/17

This page cannot be seen without first loggin in.

Some links:
Page 2

Logout

Logout.jsp

Logout

LogoutHere are some links that won't work because you logged out.
Page 1

Page 2


17/17

The logging out is done with a single

method call to invalidate the users

session.

Some links are provided to show

that the security functions aresupported; trying to visit pages again

redirects the user to the login form.

sharing data: jsp security, authentication and integrity

Documents