MELJUN_CORTES_JEDI Slides Web Programming Chapter11 Web Security

8/3/2019 MELJUN_CORTES_JEDI Slides Web Programming Chapter11 Web Security

http://slidepdf.com/reader/full/meljuncortesjedi-slides-web-programming-chapter11-web-security 1/47

Web Security

Web Programming



SSL

2Web Programming

● Secure Socket Layer

● It is a protocol layer that interposes itself between thestandard TCP/IP layer and higher, application-level

protocols such as HTTP.● It allows the server to authenticate itself to the client and

thereafter encrypts the communication channel.

● Usage of this technology guarantees a secure channelbetween the server and the client.



Enabling SSL in our

Application

3Web Programming

● Certificates

● Creating a Secure HTTP Listener



Certificates

4Web Programming

● Like a passport, it identifies the holder to others andcontains other important information.

● Usually issued by Certification Authorities (CAs).

– A CA is like a passport office – it validates the certificate owner'sidentity and signs the certificate so that it cannot be forged or tampered with.

– There are several well-known Certification Authorities, most popular of which is Verisign.

–

It is the administrator's decision as to which CA will provide theserver with a certificate.



Certificates

5Web Programming

● In the absence of a certificate from a trusted CA, atemporary one can be created using tools included withinthe Java 1.4 SDK.

●

Take note however that discerning clients will most likely notcontinue with transactions that require high confidentialityonce they detect that the certificate we use is one that wehave created for ourselves.



Certificates

6Web Programming

● Generating the certificate private key

– It is easier to perform our next set of operations in the samedirectory that the server uses to store its certificates.

%APP_SERVER_HOME%/domains/domain1/config

– Go to the specified directory using the command line. From there,perform the following command:

keytool -genkey -alias keyAlias

-keyalg RSA -keypass keypassword

-storepass storepassword

-keystore keystore.jks



Certificates

7Web Programming

(Generating the certificate private key continued)● keyAlias – the alias or ID that this certificate will be referred to.

● keypassword – the password for the private key to be used for encryption.

● storepassword – the password for the keystore.

– All key entries reside in a keystore.

● A keystore can hold one or more keys.

● The directory we are operating on already has a keystore file with an existingpassword though, so we will need to set storepass to its value: changeit.

● This password can be changed later on, using keytool:

keytool -keystore keystore.jks -storepass newPassword



Certificates

8Web Programming

● Creating the certificate

– After we have generated the key that will be used by our certificate,we can now create the certificate file itself.

keytool -export -alias keyAlias

-storepass storepassword

-file certificateFileName

-keystore keystore.jks

● The previous line tells the keytool utility to generate the certificate file using theprivate key referred to by keyAlias which is contained in the keystore.



Certificates

9Web Programming

● Managing the certificate

– For the application server to recognize the certificate we have justcreated, we need to add it up to the list of trusted certificates.

– The server contains a file named cacerts.jks which contains suchcertificates. We can add ours into this file by using the keytool:

keytool -import -v -trustcacerts

-alias keyAlias

-file certificateFileName

-keystore cacerts.jks

-keypass keypassword



Enabling SSL in our

Application

10Web Programming

● Certificates

● Creating a Secure HTTP Listener



Creating a Secure HTTP

Listener

11Web Programming

● After we have successfully created a certificate andregistered it for use in the application server, we can nowcreate an HTTP listener that can make use of the certificate.

● Having such a listener sets aside a port on our server machine which can be used for secure communications.




Listener

12Web Programming

● First, login to the administration console. On the right,expand the tab named Configuration, then expand HTTPService.




Listener

13Web Programming




Listener

14Web Programming

● Next, click on the link named HTTP Listeners, and on thepane to the right, click on the New button.

–

The values that may change are the name of the listener and theport which will be used according to the administrator's preferences.




Listener

15Web Programming




Listener

16Web Programming




Listener

17Web Programming

● Perform a server restart. Our new configuration can be triedout by accessing the following address:

https://serverAddress:listenerPort/index.html

● To utilize secure communications between the client and theserver, redirect the user to the secure listener port whenaccessing your application.



Top 10 Security Flaws

18Web Programming

● The Open Web Application Security Project (OWASP)released a list of the top 10 security flaws of webapplications according to their findings, and recommendsthat any web application be made secure against them as a

minimum standard of security. – OWASP is an open source project funded by a non-profit entity that

aims to find the causes of unsecure software and find measuresagainst them.




19Web Programming

● Unvalidated Input

● Broken Access Control

● Broken Authentication and Session Management

● Cross Site Scripting● Buffer Overflows

● Injection Flaws

● Insecure Storage

● Denial of Service

● Insecure Configuration Management



Unvalidated Input

20Web Programming

● All web applications retrieve data from the HTTP requestmade by the user and use that data to perform itsoperations.

● Hackers can manipulate any part of the request (the querystring, cookie information, headers) to try to bypass a site'ssecurity mechanism or normal control flow.

● There are different kinds of attack that relates to thisproblem.

– Cross site scripting – Buffer overflows

– Injection flaws



Unvalidated Input

21Web Programming

● There are some things to take note of when handling our application's validation.

– First, it is not enough for any web application to rely only on client-side scripting.

– Second, some applications use a "negative" approach in validation.




22Web Programming





● Injection Flaws






Broken Access Control

23Web Programming

● There are a lot of applications that categorize its users intodifferent roles and provide different levels of interaction or different kinds of content for each of those categories.

– Example: Most applications define a user role and an admin role.

Only the admin role is "authorized" to access pages or performactions that are integral to the administration of the site.

● The problem is that some applications do not effectivelyenforce this authorization.




24Web Programming

● Other problems related to access control include:

– Insecure Ids – some sites make use of some sort of id or key torefer to its users or functions. IDs can be guessed however, and if ahacker can make use of them to mimic an authorized user, then the

site is wide open to attack. – File permissions – most web and application servers rely on an

external file to provide themselves with a list of authorized users andwhich resources they can and/or cannot access. If this file is readilyaccessible to the outside, then hackers can freely modify it to includethemselves in the list of allowed users.




25Web Programming

● Steps that we can do to fix this problem:

– We can develop filters or similar components that can be applied tosensitive resources. These can ensure that only authorized userscan gain access.

– To protect ourselves from insecure Ids, we should develop theapplication such that it does not rely on the secrecy of any Ids toprovide it with access control.

– To address the problem of the permission file, these files must beplaced in locations inaccessible to web browsers and further markedin the operating system level as being available only to specificroles.




26Web Programming





● Injection Flaws






Broken Authentication and

Session Management

27Web Programming

● Authentication and session management refers to allaspects of handling user authentication and themanagement of active sessions.




Session Management

28Web Programming

● There are several areas that can be overlooked:

– Password strength – our application must maintain a minimum levelof password strength, which can be checked by looking at the length

of the password and its complexity.

– Password use – our application must enforce a maximum number of attempts that a user can use to login to the system within a giventime period.

– Password storage – passwords must never be stored as is within

our application.

– Session ID Protection – servers typically use session IDs to identifya user as participating in a session. However, if this session ID couldbe retrieved by someone in the same network, that person can thenpass himself off as the client.




Session Management

29Web Programming

● Passwords must never be hardcoded in any source code.

● One of the best ways in preventing session IDs from being

retrieved by someone in the same network is to placecommunications between the server and client in an SSL-protected channel.




30Web Programming





● Injection Flaws






Cross Site Scripting

31Web Programming

● Cross site scripting happens when someone makes use of another web application to send malicious scripts to another user.

● This can be done by embedding active content (such as

JavaScript, ActiveX objects, Flash) into a request whichgenerates HTML output that can be seen by another user.

● Once other users access these content, their browsers donot know that they are not to be trusted.



Cross Site Scripting

32Web Programming

● One of the best ways in preventing cross site scriptingattacks is to rigorously validate all data coming in from user requests (headers, cookies, user parameters, etc.).

● A negative approach should not be used: trying to filter out

all forms of embedded active content is not a a hundredpercent effective.




33Web Programming





● Injection Flaws






Buffer Overflows

34Web Programming

● Attackers can use buffer overflows to corrupt the executionstack of a web application.

● They are able to do this by sending in carefully craftedrequests that make the server perform arbitrary code.

● Buffer overflow problems are usually difficult to detect andare difficult to exploit by hackers.

● Applications running within a J2EE server is immune tothese kinds of attack.

● To ensure our safety though, it is always best to constantlymonitor the availability of patches and bug reports for theserver products that we use.





Injection Flaws

36Web Programming

● A popular vulnerability, where hackers can send in or "inject"calls to the operating system or to external resources suchas databases.

● One common injection flaw is SQL injection.

● Precautions to take:

– Rigorously validate the information from the user's request.

– Instead of using simple SELECT, INSERT, UPDATE, and DELETEstatements, create functions that perform their functional equivalent.

– Provide the application only the minimum amount of privileges that itneeds to perform its functionality.




37Web Programming





● Injection Flaws






Insecure Storage

38Web Programming

● Web applications usually need to store sensitive informationsuch as passwords, credit card information, and others.

● Due to their sensitive nature, these items are usually (or should be) encrypted to prevent casual access.

● However, such encryption implementations are sometimesweak and still vulnerable to persistent attempts.



Insecure Storage

39Web Programming

● Here are some areas where mistakes are commonly made:

– Failure to encrypt critical data.

– Insecure storage of keys, certificates, and passwords.

– Improper storage of secrets in memory.

– Poor source of randomness.

– Poor choice of algorithm.

– Attempting to invent a new encryption algorithm.



Insecure Storage

40Web Programming

● One good policy to avoid improper storage of sensitiveinformation is to not store them in the first place.

● Also, it is better to make use of external encryptionalgorithms instead of making one for your own. Make sure

that the algorithm that you will use has been subject topublic scrutiny and has proven itself to be reliable.




41Web Programming




●

Cross Site Scripting● Buffer Overflows

● Injection Flaws






Denial of Service

42Web Programming

● Denial of service (DoS) refers to a malicious attack made byhackers that makes use of multiple concurrent requests tothe server. Due to the sheer number of such requests, theserver becomes swamped and is then unable to service

other users.● DoS attacks do more than just consume bandwidth leading

to the server. They can also consume important limitedresources such as internal memory, database connection,CPU cycles, threads, and/or application specific resources.



Denial of Service

43Web Programming

● It is generally very difficult to completely protect our application from this kind of attack, as there is no 100% fool-proof solution.

● Possible solutions:

– Limit the number of resources allotted to a user to the bare minimumrequired.

– Establish load quotas which dictate just how much load a user canput in your system.

– Design your web application such that unauthorized users have little

to no access to content that will require access to the database or other expensive resources.




44

Web Programming




●

Cross Site Scripting● Buffer Overflows

● Injection Flaws


● Denial of Service● Insecure Configuration Management

Insecure Configuration



Insecure ConfigurationManagement

45

Web Programming

● Server security configuration also plays a large part indetermining how secure our application can be.

● Improper configuration on the server side can bypass allefforts of the developers to safeguard their application.



Insecure Configuration



Insecure ConfigurationManagement

47

Web Programming

(Examples of server configuration errors continued)

– Default accounts with default passwords.

– Accessible administrative or debugging functions.

– Overly informative error messages.

– Misconfigured SSL certificates and encryption settings.

– Use of self-signed certificates to achieve authentication.

– Use of default certificates.

– Improper authentication with external systems.

Documents

MELJUN_CORTES_JEDI Slides Web Programming Chapter11 Web Security