Executive Report

Acunetix Website Audit

1 August, 2015

Developer Report

Generated by Acunetix WVS Reporter (v9.5 Build 20140505)

Scan of http://demo.testfire.net:80/

Scan information

Scan details

Start time 8/1/2015 9:32:48 PM

Finish time 8/1/2015 9:54:17 PM

Scan time 21 minutes, 29 seconds

Profile Default

Server information

Responsive True

Server banner Microsoft-IIS/8.0

Server OS Windows

Server technologies ASP.NET

Threat level

Acunetix Threat Level 3

One or more high-severity type vulnerabilities have been discovered by the scanner. Amalicious user can exploit these vulnerabilities and compromise the backend databaseand/or deface your website.

Alerts distribution

High

Medium

Low

Informational 33

16

11

12

72Total alerts found

Knowledge base

List of file extensions

File extensions can provide information on what technologies are being used on this website.List of file extensions detected: - aspx => 28 file(s)- css => 1 file(s)- asmx => 1 file(s)- js => 1 file(s)- txt => 2 file(s)- swf => 1 file(s)- htm => 6 file(s)- xml => 1 file(s)- rtf => 2 file(s)

Top 10 response times

The files listed below had the slowest response times measured during the crawling process. The average response timefor this site was 499.50 ms. These files could be targetted in denial of service attacks. 1. /bank/queryxpath.aspx, response time 1264 ms GET /bank/queryxpath.aspx HTTP/1.1Pragma: no-cacheCache-Control: no-cacheReferer: http://demo.testfire.net/bank/

2Acunetix Website Audit

Acunetix-Aspect: enabledAcunetix-Aspect-Password: 082119f75623eb7abd7bf357698ff66cAcunetix-Aspect-Queries: filelist;aspectalertsCookie: ASP.NET_SessionId=rx35k455p05mwieaeevyb445; amSessionId=15731163468; lang=Host: demo.testfire.netConnection: Keep-aliveAccept-Encoding: gzip,deflateUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.63Safari/537.36Acunetix-Product: WVS/9.0 (Acunetix Web Vulnerability Scanner - Free Edition)Acunetix-Scanning-agreement: Third Party Scanning PROHIBITEDAcunetix-User-agreement: http://www.acunetix.com/wvs/disc.htmAccept: */* 2. /default.aspx, response time 592 ms GET /default.aspx HTTP/1.1Pragma: no-cacheCache-Control: no-cacheReferer: http://demo.testfire.net/Acunetix-Aspect: enabledAcunetix-Aspect-Password: 082119f75623eb7abd7bf357698ff66cAcunetix-Aspect-Queries: filelist;aspectalertsCookie: ASP.NET_SessionId=rx35k455p05mwieaeevyb445; amSessionId=15731163468Host: demo.testfire.netConnection: Keep-aliveAccept-Encoding: gzip,deflateUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.63Safari/537.36Acunetix-Product: WVS/9.0 (Acunetix Web Vulnerability Scanner - Free Edition)Acunetix-Scanning-agreement: Third Party Scanning PROHIBITEDAcunetix-User-agreement: http://www.acunetix.com/wvs/disc.htmAccept: */* 3. /comment.aspx, response time 577 ms POST /comment.aspx HTTP/1.1Pragma: no-cacheCache-Control: no-cacheReferer: http://demo.testfire.net/feedback.aspxContent-Length: 101Content-Type: application/x-www-form-urlencodedAcunetix-Aspect: enabledAcunetix-Aspect-Password: 082119f75623eb7abd7bf357698ff66cAcunetix-Aspect-Queries: filelist;aspectalertsCookie: ASP.NET_SessionId=rx35k455p05mwieaeevyb445; amSessionId=15731163468Host: demo.testfire.netConnection: Keep-aliveAccept-Encoding: gzip,deflateUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.63Safari/537.36Acunetix-Product: WVS/9.0 (Acunetix Web Vulnerability Scanner - Free Edition)Acunetix-Scanning-agreement: Third Party Scanning PROHIBITEDAcunetix-User-agreement: http://www.acunetix.com/wvs/disc.htmAccept: */* cfile=comments.txt&comments=1&email_addr=3137%20Laguna%20Street&name=scugpasj&subject=1&submit=Submit4. /bank/ws.asmx, response time 577 ms GET /bank/ws.asmx?op=IsValidUser HTTP/1.1Pragma: no-cacheCache-Control: no-cacheReferer: http://demo.testfire.net/bank/ws.asmxAcunetix-Aspect: enabledAcunetix-Aspect-Password: 082119f75623eb7abd7bf357698ff66cAcunetix-Aspect-Queries: filelist;aspectalertsCookie: ASP.NET_SessionId=rx35k455p05mwieaeevyb445; amSessionId=15731163468; lang=


Host: demo.testfire.netConnection: Keep-aliveAccept-Encoding: gzip,deflateUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.63Safari/537.36Acunetix-Product: WVS/9.0 (Acunetix Web Vulnerability Scanner - Free Edition)Acunetix-Scanning-agreement: Third Party Scanning PROHIBITEDAcunetix-User-agreement: http://www.acunetix.com/wvs/disc.htmAccept: */*

List of files with inputs

These files have at least one input (GET or POST). - / - 5 inputs- /search.aspx - 1 inputs- /default.aspx - 1 inputs- /bank/login.aspx - 1 inputs- /bank/ws.asmx - 2 inputs- /survey_questions.aspx - 1 inputs- /disclaimer.htm - 1 inputs- /comment.aspx - 1 inputs- /subscribe.aspx - 1 inputs

List of authentication pages

This is a list of pages that require HTTP authentication. - /bank/members

List of external hosts

These hosts were linked from this website but they were not scanned because they are not listed in the list of hostsallowed.(Settings->Scanners settings->Scanner->List of hosts allowed). - www.watchfire.com- fpdownload.macromedia.com- www.newspapersyndications.tv- www.cert.org- www.altoromutual.com- www.microsoft.com- www.netscape.com

List of email addresses

List of all email addresses found on this host. - [email protected]

Alerts summary

Blind SQL Injection

Classification

Base Score: 6.8 - Access Vector: Network- Access Complexity: Medium- Authentication: None- Confidentiality Impact: Partial- Integrity Impact: Partial- Availability Impact: Partial

CVSS

CWE CWE-89

Affected items Variations2/bank/login.aspx


Cross site scripting (verified)

Classification

Base Score: 4.4 - Access Vector: Network- Access Complexity: Medium- Authentication: None- Confidentiality Impact: None- Integrity Impact: Partial- Availability Impact: None

CVSS

CWE CWE-79


1/comment.aspx

1/search.aspx

1/subscribe.aspx

Directory traversal

Classification


CVSS

CWE CWE-22

Affected items Variations1/default.aspx

DOM-based cross site scripting

Classification

Base Score: 4.4 - Access Vector: Network- Access Complexity: Medium- Authentication: None- Confidentiality Impact: None- Integrity Impact: Partial- Availability Impact: None

CVSS

CWE CWE-79

Affected items Variations1/disclaimer.htm

Microsoft IIS tilde directory enumeration

Classification

Base Score: 5.0 - Access Vector: Network- Access Complexity: Low- Authentication: None- Confidentiality Impact: Partial- Integrity Impact: None- Availability Impact: None

CVSS

CWE CWE-20

Affected items Variations1/


SQL injection

Classification


CVSS

CWE CWE-89


1/subscribe.aspx

Application error message

Classification


CVSS

CWE CWE-200


1/subscribe.aspx

Basic authentication over HTTP

Classification


CVSS

CWE CWE-16

Affected items Variations1/bank/members/

Directory listing

Classification


CVSS

CWE CWE-538

Affected items Variations1/bank

1/pr


HTML form without CSRF protection

Classification

Base Score: 2.6 - Access Vector: Network- Access Complexity: High- Authentication: None- Confidentiality Impact: None- Integrity Impact: Partial- Availability Impact: None

CVSS

CWE CWE-352


1/bank/login.aspx

1/feedback.aspx

1/subscribe.aspx

User credentials are sent in clear text

Classification


CVSS

CWE CWE-310


ASP.NET debugging enabled

Classification


CVSS

CWE CWE-16


1/bank


Clickjacking: X-Frame-Options header missing

Classification


CVSS

CWE CWE-693

Affected items Variations1Web Server

Login page password-guessing attack

Classification


CVSS

CWE CWE-307


OPTIONS method is enabled

Classification


CVSS

CWE CWE-200

Affected items Variations1Web Server

Possible sensitive directories

Classification


CVSS

CWE CWE-200

Affected items Variations1/admin


Possible sensitive files

Classification


CVSS

CWE CWE-200

Affected items Variations1/test.aspx

Session Cookie without HttpOnly flag set

Classification

Base Score: 0.0 - Access Vector: Network- Access Complexity: Low- Authentication: None- Confidentiality Impact: None- Integrity Impact: None- Availability Impact: None

CVSS

CWE CWE-16


Session Cookie without Secure flag set

Classification


CVSS

CWE CWE-16



Broken links

Classification


CVSS

CWE CWE-16

Affected items Variations1/bank/account.aspx.cs

1/bank/apply.aspx.cs

1/bank/bank.master

1/bank/bank.master.cs

1/bank/customize.aspx.cs

1/bank/login.aspx.cs

1/bank/logout.aspx.cs

1/bank/main.aspx.cs

1/bank/queryxpath.aspx.cs

1/bank/transaction.aspx.cs

1/bank/transfer.aspx.cs

1/inside_points_of_interest.htm

Email address found

Classification


CVSS

CWE CWE-200

Affected items Variations1/business_cards.htm

1/cache.aspx

1/callback.aspx

1/files.aspx

1/header.aspx

1/home.aspx

1/index.aspx

1/info.aspx

1/inside_about.htm

1/inside_investor.htm

1/log.aspx

1/login.aspx

1/orders.aspx

1/robots.txt

1/security.htm

1/signup.aspx


GHDB: Typical login page


1/bank/login.aspx (825f8b5076aa7df703fc45c8fed863e5)

1/bank/login.aspx.cs

1/login.aspx

Password type input with auto-complete enabled

Classification


CVSS

CWE CWE-200



Alert details

Blind SQL Injection

HighSeverity

ValidationType

Scripting (Blind_Sql_Injection.script)Reported by module

Impact

Description

This script is possibly vulnerable to SQL Injection attacks. SQL injection is a vulnerability that allows an attacker to alter back-end SQL statements by manipulating the user input.An SQL injection occurs when web applications accept user input that is directly placed into a SQL statement and doesn'tproperly filter out dangerous characters. This is one of the most common application layer attacks currently being used on the Internet. Despite the fact that it isrelatively easy to protect against, there is a large number of web applications vulnerable.

An attacker may execute arbitrary SQL statements on the vulnerable system. This may compromise the integrity of yourdatabase and/or expose sensitive information. Depending on the back-end database in use, SQL injection vulnerabilities lead to varying levels of data/system accessfor the attacker. It may be possible to not only manipulate existing queries, but to UNION in arbitrary data, use subselects, or append additional queries. In some cases, it may be possible to read in or write out to files, or to execute shellcommands on the underlying operating system. Certain SQL Servers such as Microsoft SQL Server contain stored and extended procedures (database serverfunctions). If an attacker can obtain access to these procedures it may be possible to compromise the entire machine.

Recommendation

Your script should filter metacharacters from user input. Check detailed information for more information about fixing this vulnerability.

References

VIDEO: SQL Injection tutorial

OWASP PHP Top 5

SQL Injection Walkthrough

OWASP Injection Flaws

Acunetix SQL Injection Attack

How to check for SQL injection vulnerabilities

Detailed information

Quote from SQL Injection Attacks by Example - http://www.unixwiz.net/techtips/sql-injection.html SQL injection mitigations We believe that web application developers often simply do not think about "surprise inputs", but security people do(including the bad guys), so there are three broad approaches that can be applied here. Sanitize the input It's absolutely vital to sanitize user inputs to insure that they do not contain dangerous codes, whether to the SQL serveror to HTML itself. One's first idea is to strip out "bad stuff", such as quotes or semicolons or escapes, but this is amisguided attempt. Though it's easy to point out some dangerous characters, it's harder to point to all of them. The language of the web is full of special characters and strange markup (including alternate ways of representing thesame characters), and efforts to authoritatively identify all "bad stuff" are unlikely to be successful. Instead, rather than "remove known bad data", it's better to "remove everything but known good data": this distinction iscrucial. Since - in our example - an email address can contain only these characters:


http://www.acunetix.com/blog/web-security-zone/video-sql-injection-tutorial/

http://www.owasp.org/index.php/PHP_Top_5

http://www.securiteam.com/securityreviews/5DP0N1P76E.html

http://www.owasp.org/index.php/Injection_Flaws

http://www.acunetix.com/websitesecurity/sql-injection.htm

http://www.acunetix.com/websitesecurity/sql-injection2/

abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789 @.-_+ There is really no benefit in allowing characters that could not be valid, and rejecting them early - presumably with anerror message - not only helps forestall SQL Injection, but also catches mere typos early rather than stores them into thedatabase. Be aware that "sanitizing the input" doesn't mean merely "remove the quotes", because even "regular" characters can betroublesome. In an example where an integer ID value is being compared against the user input (say, a numeric PIN): SELECT fieldlist FROM table WHERE id = 23 OR 1=1; -- Boom! Always matches! In practice, however, this approach is highly limited because there are so few fields for which it's possible to outrightexclude many of the dangerous characters. For "dates" or "email addresses" or "integers" it may have merit, but for anykind of real application, one simply cannot avoid the other mitigations. Escape/Quotesafe the input Even if one might be able to sanitize a phone number or email address, one cannot take this approach with a "name"field lest one wishes to exclude the likes of Bill O'Reilly from one's application: a quote is simply a valid character for thisfield. One includes an actual single quote in an SQL string by putting two of them together, so this suggests the obvious - butwrong! - technique of preprocessing every string to replicate the single quotes: SELECT fieldlist FROM customers WHERE name = 'Bill O''Reilly'; -- works OK However, this naive approach can be beaten because most databases support other string escape mechanisms.MySQL, for instance, also permits \' to escape a quote, so after input of \'; DROP TABLE users; -- is "protected" bydoubling the quotes, we get: SELECT fieldlist FROM customers WHERE name = '\''; DROP TABLE users; --'; -- Boom! The expression '\'' is a complete string (containing just one single quote), and the usual SQL shenanigans follow. Itdoesn't stop with backslashes either: there is Unicode, other encodings, and parsing oddities all hiding in the weeds totrip up the application designer. Getting quotes right is notoriously difficult, which is why many database interface languages provide a function that doesit for you. When the same internal code is used for "string quoting" and "string parsing", it's much more likely that theprocess will be done properly and safely. Some examples are the MySQL function mysql_real_escape_string() and perl DBD method $dbh->quote($value). Thesemethods must be used. Use bound parameters (the PREPARE statement) Though quotesafing is a good mechanism, we're still in the area of "considering user input as SQL", and a much betterapproach exists: bound parameters, which are supported by essentially all database programming interfaces. In thistechnique, an SQL statement string is created with placeholders - a question mark for each parameter - and it's compiled("prepared", in SQL parlance) into an internal form. Later, this prepared query is "executed" with a list of parameters: Example in perl


$sth = $dbh->prepare("SELECT email, userid FROM members WHERE email = ?;"); $sth->execute($email); Thanks to Stefan Wagner, this demonstrates bound parameters in Java: Insecure version Statement s = connection.createStatement(); ResultSet rs = s.executeQuery("SELECT email FROM member WHERE name = " + formField); // *boom* Secure version PreparedStatement ps = connection.prepareStatement( "SELECT email FROM member WHERE name = ?"); ps.setString(1, formField); ResultSet rs = ps.executeQuery(); Here, $email is the data obtained from the user's form, and it is passed as positional parameter #1 (the first questionmark), and at no point do the contents of this variable have anything to do with SQL statement parsing. Quotes,semicolons, backslashes, SQL comment notation - none of this has any impact, because it's "just data". There simply isnothing to subvert, so the application is be largely immune to SQL injection attacks. There also may be some performance benefits if this prepared query is reused multiple times (it only has to be parsedonce), but this is minor compared to the enormous security benefits. This is probably the single most important step onecan take to secure a web application. Limit database permissions and segregate users In the case at hand, we observed just two interactions that are made not in the context of a logged-in user: "log in" and"send me password". The web application ought to use a database connection with the most limited rights possible:query-only access to the members table, and no access to any other table. The effect here is that even a "successful" SQL injection attack is going to have much more limited success. Here, we'dnot have been able to do the UPDATE request that ultimately granted us access, so we'd have had to resort to otheravenues. Once the web application determined that a set of valid credentials had been passed via the login form, it would thenswitch that session to a database connection with more rights. It should go almost without saying that sa rights should never be used for any web-based application. Use stored procedures for database access When the database server supports them, use stored procedures for performing access on the application's behalf,which can eliminate SQL entirely (assuming the stored procedures themselves are written properly). By encapsulating the rules for a certain action - query, update, delete, etc. - into a single procedure, it can be tested anddocumented on a standalone basis and business rules enforced (for instance, the "add new order" procedure mightreject that order if the customer were over his credit limit). For simple queries this might be only a minor benefit, but as the operations become more complicated (or are used inmore than one place), having a single definition for the operation means it's going to be more robust and easier tomaintain. Note: it's always possible to write a stored procedure that itself constructs a query dynamically: this provides noprotection against SQL Injection - it's only proper binding with prepare/execute or direct SQL statements with boundvariables that provide this protection. Isolate the webserver Even having taken all these mitigation steps, it's nevertheless still possible to miss something and leave the server opento compromise. One ought to design the network infrastructure to assume that the bad guy will have full administratoraccess to the machine, and then attempt to limit how that can be leveraged to compromise other things. For instance, putting the machine in a DMZ with extremely limited pinholes "inside" the network means that even getting


complete control of the webserver doesn't automatically grant full access to everything else. This won't stop everything,of course, but it makes it a lot harder. Configure error reporting The default error reporting for some frameworks includes developer debugging information, and this cannot be shown tooutside users. Imagine how much easier a time it makes for an attacker if the full query is shown, pointing to the syntaxerror involved. This information is useful to developers, but it should be restricted - if possible - to just internal users.

Affected items

Details

/bank/login.aspx

URL encoded POST input passw was set to -1' OR 3*2*1=6 AND 000589=000589 -- Tests performed: - -1' OR 2+589-589-1=0+0+0+1 -- => TRUE- -1' OR 3+589-589-1=0+0+0+1 -- => FALSE- -1' OR 3*2<(0+5+589-589) -- => FALSE- -1' OR 3*2>(0+5+589-589) -- => FALSE- -1' OR 2+1-1-1=1 AND 000589=000589 -- => TRUE- -1' OR 000589=000589 AND 3 ... (line truncated)

POST /bank/login.aspx HTTP/1.1

Content-Length: 80

Content-Type: application/x-www-form-urlencoded

X-Requested-With: XMLHttpRequest

Referer: http://demo.testfire.net:80/

Cookie: ASP.NET_SessionId=rx35k455p05mwieaeevyb445; amSessionId=15731163468; lang=

Host: demo.testfire.net

Connection: Keep-alive

Accept-Encoding: gzip,deflate

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)

Chrome/28.0.1500.63 Safari/537.36

Acunetix-Product: WVS/9.0 (Acunetix Web Vulnerability Scanner - Free Edition)

Acunetix-Scanning-agreement: Third Party Scanning PROHIBITED

Acunetix-User-agreement: http://www.acunetix.com/wvs/disc.htm

Accept: */*

btnSubmit=Login&passw=-1'%20OR%203*2*1%3d6%20AND%20000589%3d000589%20--%20&uid=1

Request headers

HTTP/1.1 500 Internal Server Error

Cache-Control: no-cache

Pragma: no-cache

Content-Type: text/html

Expires: -1

Server: Microsoft-IIS/8.0

X-AspNet-Version: 2.0.50727

X-Powered-By: ASP.NET

Date: Thu, 16 Jul 2015 06:59:07 GMT

Connection: close

Content-Length: 5297

Response headers


Details

/bank/login.aspx

URL encoded POST input uid was set to -1' OR 3*2*1=6 AND 000373=000373 -- Tests performed: - -1' OR 2+373-373-1=0+0+0+1 -- => TRUE- -1' OR 3+373-373-1=0+0+0+1 -- => FALSE- -1' OR 3*2<(0+5+373-373) -- => FALSE- -1' OR 3*2>(0+5+373-373) -- => FALSE- -1' OR 2+1-1-1=1 AND 000373=000373 -- => TRUE- -1' OR 000373=000373 AND 3+1 ... (line truncated)


Content-Length: 95


X-Requested-With: XMLHttpRequest







Chrome/28.0.1500.63 Safari/537.36




Accept: */*

btnSubmit=Login&passw=g00dPa%24%24w0rD&uid=-1'%20OR%203*2*1%3d6%20AND%20000373%3d000373%

20--%20

Request headers

HTTP/1.1 302 Found


Pragma: no-cache

Content-Length: 136

Content-Type: text/html; charset=utf-8

Expires: -1

Location: /bank/main.aspx



Set-Cookie:

amUserInfo=UserName=LTEnIE9SIDMqMioxPTYgQU5EIDAwMDM3Mz0wMDAzNzMgLS0g&Password=ZzAwZFBhJC

R3MHJE; expires=Thu, 16-Jul-2015 09:59:42 GMT; path=/

Set-Cookie: amUserId=1; path=/


Date: Thu, 16 Jul 2015 06:59:42 GMT

Response headers


Cross site scripting (verified)

HighSeverity

ValidationType

Scripting (XSS.script)Reported by module

Impact

Description

This script is possibly vulnerable to Cross Site Scripting (XSS) attacks. Cross site scripting (also referred to as XSS) is a vulnerability that allows an attacker to send malicious code (usually inthe form of Javascript) to another user. Because a browser cannot know if the script should be trusted or not, it willexecute the script in the user context allowing the attacker to access any cookies or session tokens retained by thebrowser.

Malicious users may inject JavaScript, VBScript, ActiveX, HTML or Flash into a vulnerable application to fool a user inorder to gather data from them. An attacker can steal the session cookie and take over the account, impersonating theuser. It is also possible to modify the content of the page presented to the user.

Recommendation

Your script should filter metacharacters from user input.

References

Acunetix Cross Site Scripting Attack

VIDEO: How Cross-Site Scripting (XSS) Works

The Cross Site Scripting Faq

OWASP Cross Site Scripting

XSS Annihilation

XSS Filter Evasion Cheat Sheet

Cross site scripting

OWASP PHP Top 5

How To: Prevent Cross-Site Scripting in ASP.NET


Quote from The Cross Site Scripting FAQ - http://www.cgisecurity.com/articles/xss-faq.shtml Introduction Websites today are more complex than ever, containing a lot of dynamic content making the experience for the usermore enjoyable. Dynamic content is achieved through the use of web applications which can deliver different output to auser depending on their settings and needs. Dynamic websites suffer from a threat that static websites don't, called"Cross Site Scripting" (or XSS dubbed by other security professionals). Currently small informational tidbits about CrossSite Scripting holes exist but none really explain them to an average person or administrator. This FAQ was written toprovide a better understanding of this emerging threat, and to give guidance on detection and prevention. "What is Cross Site Scripting?" Cross site scripting (also known as XSS) occurs when a web application gathers malicious data from a user. The data isusually gathered in the form of a hyperlink which contains malicious content within it. The user will most likely click on thislink from another website, instant message, or simply just reading a web board or email message. Usually the attackerwill encode the malicious portion of the link to the site in HEX (or other encoding methods) so the request is lesssuspicious looking to the user when clicked on. After the data is collected by the web application, it creates an outputpage for the user containing the malicious data that was originally sent to it, but in a manner to make it appear as validcontent from the website. Many popular guestbook and forum programs allow users to submit posts with html andjavascript embedded in them. If for example I was logged in as "john" and read a message by "joe" that containedmalicious javascript in it, then it may be possible for "joe" to hijack my session just by reading his bulletin board post.Further details on how attacks like this are accomplished via "cookie theft" are explained in detail below. "What does XSS and CSS mean?" Often people refer to Cross Site Scripting as CSS. There has been a lot of confusion with Cascading Style Sheets (CSS)and cross site scripting. Some security people refer to Cross Site Scripting as XSS. If you hear someone say "I found a


http://www.acunetix.com/websitesecurity/cross-site-scripting.htm

http://www.acunetix.com/blog/web-security-zone/video-how-cross-site-scripting-xss-works/

http://www.cgisecurity.com/xss-faq.html

http://www.owasp.org/index.php/Cross_Site_Scripting

http://ha.ckers.org/blog/20060602/xss-annihilation/

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

http://en.wikipedia.org/wiki/Cross-site_scripting


http://msdn.microsoft.com/en-us/library/ms998274.aspx

XSS hole", they are talking about Cross Site Scripting for certain. "What are the threats of Cross Site Scripting?" Often attackers will inject JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable application to fool a user (Readbelow for further details) in order to gather data from them. Everything from account hijacking, changing of user settings,cookie theft/poisoning, or false advertising is possible. New malicious uses are being found every day for XSS attacks.The post below by Brett Moore brings up a good point with regard to "Denial Of Service", and potential "auto-attacking" ofhosts if a user simply reads a post on a message board. "What can I do to protect myself as a vendor?" This is a simple answer. Never trust user input and always filter metacharacters. This will eliminate the majority of XSSattacks. Converting < and > to < and > is also suggested when it comes to script output. Remember XSS holes canbe damaging and costly to your business if abused. Often attackers will disclose these holes to the public, which canerode customer and public confidence in the security and privacy of your organization's site. Filtering < and > alone willnot solve all cross site scripting attacks and it is suggested you also attempt to filter out ( and ) by translating them to( and ), and also # and & by translating them to &#35 (#) and &#38 (&). "What can I do to protect myself as a user?" The easiest way to protect yourself as a user is to only follow links from the main website you wish to view. If you visitone website and it links to CNN for example, instead of clicking on it visit CNN's main site and use its search engine tofind the content. This will probably eliminate ninety percent of the problem. Sometimes XSS can be executedautomatically when you open an email, email attachment, read a guestbook, or bulletin board post. If you plan onopening an email, or reading a post on a public board from a person you don't know BE CAREFUL. One of the best waysto protect yourself is to turn off Javascript in your browser settings. In IE turn your security settings to high. This canprevent cookie theft, and in general is a safer thing to do. "How common are XSS holes?" Cross site scripting holes are gaining popularity among hackers as easy holes to find in large websites. Websites fromFBI.gov, CNN.com, Time.com, Ebay, Yahoo, Apple computer, Microsoft, Zdnet, Wired, and Newsbytes have all had oneform or another of XSS bugs. Every month roughly 10-25 XSS holes are found in commercial products and advisories are published explaining thethreat. "Does encryption protect me?" Websites that use SSL (https) are in no way more protected than websites that are not encrypted. The web applicationswork the same way as before, except the attack is taking place in an encrypted connection. People often think thatbecause they see the lock on their browser it means everything is secure. This just isn't the case. "Can XSS holes allow command execution?" XSS holes can allow Javascript insertion, which may allow for limited execution. If an attacker were to exploit a browserflaw (browser hole) it could then be possible to execute commands on the client's side. If command execution werepossible it would only be possible on the client side. In simple terms XSS holes can be used to help exploit other holesthat may exist in your browser. "What if I don't feel like fixing a CSS/XSS Hole?" By not fixing an XSS hole this could allow possible user account compromise in portions of your site as they get added orupdated. Cross Site Scripting has been found in various large sites recently and have been widely publicized. Leftunrepaired, someone may discover it and publish a warning about your company. This may damage your company'sreputation, depicting it as being lax on security matters. This of course also sends the message to your clients that youaren't dealing with every problem that arises, which turns into a trust issue. If your client doesn't trust you why would theywish to do business with you?

Affected items

Details

/bank/login.aspx

URL encoded POST input uid was set to 1" onmouseover=prompt(931034) bad="The input is reflected inside a tag parameter between double quotes.



Content-Length: 90








Chrome/28.0.1500.63 Safari/537.36




Accept: */*

btnSubmit=Login&passw=g00dPa%24%24w0rD&uid=1%22%20onmouseover%3dprompt(931034)%20bad%3d%

22

Request headers

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Date: Thu, 16 Jul 2015 06:59:03 GMT

Response headers

Details

/comment.aspx

URL encoded POST input name was set to ctuysydc'"()&%<ScRiPt >prompt(975117)</ScRiPt>

POST /comment.aspx HTTP/1.1

Content-Length: 147








Chrome/28.0.1500.63 Safari/537.36




Accept: */*

cfile=comments.txt&comments=1&email_addr=3137%20Laguna%20Street&name=ctuysydc'%22()%26%2

5<ScRiPt%20>prompt(975117)</ScRiPt>&subject=1&submit=Submit

Request headers

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Date: Thu, 16 Jul 2015 07:00:04 GMT

Response headers


Details

/search.aspx

URL encoded GET input txtSearch was set to the'"()&%<ScRiPt >prompt(922589)</ScRiPt>

GET /search.aspx?txtSearch=the'%22()%26%25<ScRiPt%20>prompt(922589)</ScRiPt> HTTP/1.1







Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK

Cache-Control: private






Date: Thu, 16 Jul 2015 06:58:32 GMT

Response headers

Details

/subscribe.aspx

URL encoded POST input txtEmail was set to sample%40email.tst<ScRiPt >prompt(966807)</ScRiPt>The input is reflected inside a text element.

POST /subscribe.aspx HTTP/1.1

Content-Length: 83








Chrome/28.0.1500.63 Safari/537.36




Accept: */*

btnSubmit=Subscribe&txtEmail=sample%2540email.tst<ScRiPt%20>prompt(966807)</ScRiPt>

Request headers

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Date: Thu, 16 Jul 2015 06:59:37 GMT

Response headers


Directory traversal

HighSeverity

ValidationType

Scripting (Directory_Traversal.script)Reported by module

Impact

Description

This script is possibly vulnerable to directory traversal attacks. Directory Traversal is a vulnerability which allows attackers to access restricted directories and execute commandsoutside of the web server's root directory.

By exploiting directory traversal vulnerabilities, attackers step out of the root directory and access files in otherdirectories. As a result, attackers might view restricted files or execute commands, leading to a full compromise of theWeb server.

Recommendation


References

Acunetix Directory Traversal Attacks

Affected items

Details

/default.aspx

URL encoded GET input content was set to ../../../../../../../../../../windows/win.ini%00.htmFile contents found: ; for 16-bit app support

GET /default.aspx?content=../../../../../../../../../../windows/win.ini%00.htm HTTP/1.1







Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Date: Thu, 16 Jul 2015 07:00:38 GMT

Response headers


http://www.acunetix.com/websitesecurity/directory-traversal.htm

DOM-based cross site scripting

HighSeverity

ValidationType

DeepScanReported by module

Impact

Description

This script is possibly vulnerable to Cross Site Scripting (XSS) attacks. Cross site scripting (also referred to as XSS) is a vulnerability that allows an attacker to send malicious code (usually inthe form of Javascript) to another user. Because a browser cannot know if the script should be trusted or not, it willexecute the script in the user context allowing the attacker to access any cookies or session tokens retained by thebrowser. While a traditional cross-site scripting vulnerability occurs on the server-side code, document object model basedcross-site scripting is a type of vulnerability which affects the script code in the client's browser.

Malicious users may inject JavaScript, VBScript, ActiveX, HTML or Flash into a vulnerable application to fool a user inorder to gather data from them. An attacker can steal the session cookie and take over the account, impersonating theuser. It is also possible to modify the content of the page presented to the user.

Recommendation


References

OWASP Cross Site Scripting

How To: Prevent Cross-Site Scripting in ASP.NET

OWASP PHP Top 5

Cross site scripting

XSS Annihilation

The Cross Site Scripting Faq

VIDEO: How Cross-Site Scripting (XSS) Works

Acunetix Cross Site Scripting Attack

XSS Filter Evasion Cheat Sheet


Quote from The Cross Site Scripting FAQ - http://www.cgisecurity.com/articles/xss-faq.shtml Introduction Websites today are more complex than ever, containing a lot of dynamic content making the experience for the usermore enjoyable. Dynamic content is achieved through the use of web applications which can deliver different output to auser depending on their settings and needs. Dynamic websites suffer from a threat that static websites don't, called"Cross Site Scripting" (or XSS dubbed by other security professionals). Currently small informational tidbits about CrossSite Scripting holes exist but none really explain them to an average person or administrator. This FAQ was written toprovide a better understanding of this emerging threat, and to give guidance on detection and prevention. "What is Cross Site Scripting?" Cross site scripting (also known as XSS) occurs when a web application gathers malicious data from a user. The data isusually gathered in the form of a hyperlink which contains malicious content within it. The user will most likely click on thislink from another website, instant message, or simply just reading a web board or email message. Usually the attackerwill encode the malicious portion of the link to the site in HEX (or other encoding methods) so the request is lesssuspicious looking to the user when clicked on. After the data is collected by the web application, it creates an outputpage for the user containing the malicious data that was originally sent to it, but in a manner to make it appear as validcontent from the website. Many popular guestbook and forum programs allow users to submit posts with html andjavascript embedded in them. If for example I was logged in as "john" and read a message by "joe" that containedmalicious javascript in it, then it may be possible for "joe" to hijack my session just by reading his bulletin board post.Further details on how attacks like this are accomplished via "cookie theft" are explained in detail below. "What does XSS and CSS mean?"


http://www.owasp.org/index.php/Cross_Site_Scripting

http://msdn.microsoft.com/en-us/library/ms998274.aspx


http://en.wikipedia.org/wiki/Cross-site_scripting

http://ha.ckers.org/blog/20060602/xss-annihilation/

http://www.cgisecurity.com/xss-faq.html

http://www.acunetix.com/blog/web-security-zone/video-how-cross-site-scripting-xss-works/

http://www.acunetix.com/websitesecurity/cross-site-scripting.htm

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

Often people refer to Cross Site Scripting as CSS. There has been a lot of confusion with Cascading Style Sheets (CSS)and cross site scripting. Some security people refer to Cross Site Scripting as XSS. If you hear someone say "I found aXSS hole", they are talking about Cross Site Scripting for certain. "What are the threats of Cross Site Scripting?" Often attackers will inject JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable application to fool a user (Readbelow for further details) in order to gather data from them. Everything from account hijacking, changing of user settings,cookie theft/poisoning, or false advertising is possible. New malicious uses are being found every day for XSS attacks.The post below by Brett Moore brings up a good point with regard to "Denial Of Service", and potential "auto-attacking" ofhosts if a user simply reads a post on a message board. "What can I do to protect myself as a vendor?" This is a simple answer. Never trust user input and always filter metacharacters. This will eliminate the majority of XSSattacks. Converting < and > to < and > is also suggested when it comes to script output. Remember XSS holes canbe damaging and costly to your business if abused. Often attackers will disclose these holes to the public, which canerode customer and public confidence in the security and privacy of your organization's site. Filtering < and > alone willnot solve all cross site scripting attacks and it is suggested you also attempt to filter out ( and ) by translating them to( and ), and also # and & by translating them to &#35 (#) and &#38 (&). "What can I do to protect myself as a user?" The easiest way to protect yourself as a user is to only follow links from the main website you wish to view. If you visitone website and it links to CNN for example, instead of clicking on it visit CNN's main site and use its search engine tofind the content. This will probably eliminate ninety percent of the problem. Sometimes XSS can be executedautomatically when you open an email, email attachment, read a guestbook, or bulletin board post. If you plan onopening an email, or reading a post on a public board from a person you don't know BE CAREFUL. One of the best waysto protect yourself is to turn off Javascript in your browser settings. In IE turn your security settings to high. This canprevent cookie theft, and in general is a safer thing to do. "How common are XSS holes?" Cross site scripting holes are gaining popularity among hackers as easy holes to find in large websites. Websites fromFBI.gov, CNN.com, Time.com, Ebay, Yahoo, Apple computer, Microsoft, Zdnet, Wired, and Newsbytes have all had oneform or another of XSS bugs. Every month roughly 10-25 XSS holes are found in commercial products and advisories are published explaining thethreat. "Does encryption protect me?" Websites that use SSL (https) are in no way more protected than websites that are not encrypted. The web applicationswork the same way as before, except the attack is taking place in an encrypted connection. People often think thatbecause they see the lock on their browser it means everything is secure. This just isn't the case. "Can XSS holes allow command execution?" XSS holes can allow Javascript insertion, which may allow for limited execution. If an attacker were to exploit a browserflaw (browser hole) it could then be possible to execute commands on the client's side. If command execution werepossible it would only be possible on the client side. In simple terms XSS holes can be used to help exploit other holesthat may exist in your browser. "What if I don't feel like fixing a CSS/XSS Hole?" By not fixing an XSS hole this could allow possible user account compromise in portions of your site as they get added orupdated. Cross Site Scripting has been found in various large sites recently and have been widely publicized. Leftunrepaired, someone may discover it and publish a warning about your company. This may damage your company'sreputation, depicting it as being lax on security matters. This of course also sends the message to your clients that youaren't dealing with every problem that arises, which turns into a trust issue. If your client doesn't trust you why would theywish to do business with you?

Affected items


Details

/disclaimer.htm

Source: LocationLocation:http://demo.testfire.net/disclaimer.htm?wvstest=javascript:domxssExecutionSink(1,"<br>()locxss")url=javascript:domxssExecutionSink(1,"<br>()locxss")&Execution Sink: document.writeHTML code written: javascript:domxssExecutionSink(1,"<br>()locxss")& ... Stack Trace: athttp://demo.testfire.net/disclaimer.htm?wvstest=javascript:domxssExecutionSink(1,%22%3Cbr%3E()locxss%22)url=javascript:domxssExecutionSink(1,%22%3Cbr%3E()locxss%22)&:34


Microsoft IIS tilde directory enumeration

HighSeverity

ConfigurationType

Scripting (IIS_Tilde_Dir_Enumeration.script)Reported by module

Impact

Description

It is possible to detect short names of files and directories which have an 8.3 file naming scheme equivalent in Windowsby using some vectors in several versions of Microsoft IIS. For instance, it is possible to detect all short-names of ".aspx"files as they have 4 letters in their extensions. This can be a major issue especially for the .Net websites which arevulnerable to direct URL access as an attacker can find important files and folders that they are not normally visible.

Possible sensitive information disclosure.

Recommendation

Consult the "Prevention Technique(s)" section from Soroush Dalili's paper on this subject. A link to this paper is listed inthe Web references section below.

References

Windows Short (8.3) Filenames - A Security Nightmare?

Microsoft IIS Shortname Scanner PoC

Affected items

Details

/

No details are available.

GET //*~1*/a.aspx?aspxerrorpath=/ HTTP/1.1






Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 404 Not Found




Date: Thu, 16 Jul 2015 07:11:36 GMT


Response headers


http://www.acunetix.com/blog/web-security-zone/windows-short-8-3-filenames-web-security-problem/

http://code.google.com/p/iis-shortname-scanner-poc/

SQL injection

HighSeverity

ValidationType

Scripting (Sql_Injection.script)Reported by module

Impact

Description

This script is possibly vulnerable to SQL Injection attacks. SQL injection is a vulnerability that allows an attacker to alter back-end SQL statements by manipulating the user input.An SQL injection occurs when web applications accept user input that is directly placed into a SQL statement and doesn'tproperly filter out dangerous characters. This is one of the most common application layer attacks currently being used on the Internet. Despite the fact that it isrelatively easy to protect against, there is a large number of web applications vulnerable.

An attacker may execute arbitrary SQL statements on the vulnerable system. This may compromise the integrity of yourdatabase and/or expose sensitive information. Depending on the back-end database in use, SQL injection vulnerabilities lead to varying levels of data/system accessfor the attacker. It may be possible to not only manipulate existing queries, but to UNION in arbitrary data, use subselects, or append additional queries. In some cases, it may be possible to read in or write out to files, or to execute shellcommands on the underlying operating system. Certain SQL Servers such as Microsoft SQL Server contain stored and extended procedures (database serverfunctions). If an attacker can obtain access to these procedures it may be possible to compromise the entire machine.

Recommendation

Your script should filter metacharacters from user input. Check detailed information for more information about fixing this vulnerability.

References

Acunetix SQL Injection Attack

VIDEO: SQL Injection tutorial

OWASP Injection Flaws

How to check for SQL injection vulnerabilities

SQL Injection Walkthrough

OWASP PHP Top 5


Quote from SQL Injection Attacks by Example - http://www.unixwiz.net/techtips/sql-injection.html SQL injection mitigations We believe that web application developers often simply do not think about "surprise inputs", but security people do(including the bad guys), so there are three broad approaches that can be applied here. Sanitize the input It's absolutely vital to sanitize user inputs to insure that they do not contain dangerous codes, whether to the SQL serveror to HTML itself. One's first idea is to strip out "bad stuff", such as quotes or semicolons or escapes, but this is amisguided attempt. Though it's easy to point out some dangerous characters, it's harder to point to all of them. The language of the web is full of special characters and strange markup (including alternate ways of representing thesame characters), and efforts to authoritatively identify all "bad stuff" are unlikely to be successful. Instead, rather than "remove known bad data", it's better to "remove everything but known good data": this distinction iscrucial. Since - in our example - an email address can contain only these characters: abcdefghijklmnopqrstuvwxyz


http://www.acunetix.com/websitesecurity/sql-injection.htm

http://www.acunetix.com/blog/web-security-zone/video-sql-injection-tutorial/

http://www.owasp.org/index.php/Injection_Flaws

http://www.acunetix.com/websitesecurity/sql-injection2/

http://www.securiteam.com/securityreviews/5DP0N1P76E.html


ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789 @.-_+ There is really no benefit in allowing characters that could not be valid, and rejecting them early - presumably with anerror message - not only helps forestall SQL Injection, but also catches mere typos early rather than stores them into thedatabase. Be aware that "sanitizing the input" doesn't mean merely "remove the quotes", because even "regular" characters can betroublesome. In an example where an integer ID value is being compared against the user input (say, a numeric PIN): SELECT fieldlist FROM table WHERE id = 23 OR 1=1; -- Boom! Always matches! In practice, however, this approach is highly limited because there are so few fields for which it's possible to outrightexclude many of the dangerous characters. For "dates" or "email addresses" or "integers" it may have merit, but for anykind of real application, one simply cannot avoid the other mitigations. Escape/Quotesafe the input Even if one might be able to sanitize a phone number or email address, one cannot take this approach with a "name"field lest one wishes to exclude the likes of Bill O'Reilly from one's application: a quote is simply a valid character for thisfield. One includes an actual single quote in an SQL string by putting two of them together, so this suggests the obvious - butwrong! - technique of preprocessing every string to replicate the single quotes: SELECT fieldlist FROM customers WHERE name = 'Bill O''Reilly'; -- works OK However, this naive approach can be beaten because most databases support other string escape mechanisms.MySQL, for instance, also permits \' to escape a quote, so after input of \'; DROP TABLE users; -- is "protected" bydoubling the quotes, we get: SELECT fieldlist FROM customers WHERE name = '\''; DROP TABLE users; --'; -- Boom! The expression '\'' is a complete string (containing just one single quote), and the usual SQL shenanigans follow. Itdoesn't stop with backslashes either: there is Unicode, other encodings, and parsing oddities all hiding in the weeds totrip up the application designer. Getting quotes right is notoriously difficult, which is why many database interface languages provide a function that doesit for you. When the same internal code is used for "string quoting" and "string parsing", it's much more likely that theprocess will be done properly and safely. Some examples are the MySQL function mysql_real_escape_string() and perl DBD method $dbh->quote($value). Thesemethods must be used. Use bound parameters (the PREPARE statement) Though quotesafing is a good mechanism, we're still in the area of "considering user input as SQL", and a much betterapproach exists: bound parameters, which are supported by essentially all database programming interfaces. In thistechnique, an SQL statement string is created with placeholders - a question mark for each parameter - and it's compiled("prepared", in SQL parlance) into an internal form. Later, this prepared query is "executed" with a list of parameters: Example in perl $sth = $dbh->prepare("SELECT email, userid FROM members WHERE email = ?;"); $sth->execute($email);


Thanks to Stefan Wagner, this demonstrates bound parameters in Java: Insecure version Statement s = connection.createStatement(); ResultSet rs = s.executeQuery("SELECT email FROM member WHERE name = " + formField); // *boom* Secure version PreparedStatement ps = connection.prepareStatement( "SELECT email FROM member WHERE name = ?"); ps.setString(1, formField); ResultSet rs = ps.executeQuery(); Here, $email is the data obtained from the user's form, and it is passed as positional parameter #1 (the first questionmark), and at no point do the contents of this variable have anything to do with SQL statement parsing. Quotes,semicolons, backslashes, SQL comment notation - none of this has any impact, because it's "just data". There simply isnothing to subvert, so the application is be largely immune to SQL injection attacks. There also may be some performance benefits if this prepared query is reused multiple times (it only has to be parsedonce), but this is minor compared to the enormous security benefits. This is probably the single most important step onecan take to secure a web application. Limit database permissions and segregate users In the case at hand, we observed just two interactions that are made not in the context of a logged-in user: "log in" and"send me password". The web application ought to use a database connection with the most limited rights possible:query-only access to the members table, and no access to any other table. The effect here is that even a "successful" SQL injection attack is going to have much more limited success. Here, we'dnot have been able to do the UPDATE request that ultimately granted us access, so we'd have had to resort to otheravenues. Once the web application determined that a set of valid credentials had been passed via the login form, it would thenswitch that session to a database connection with more rights. It should go almost without saying that sa rights should never be used for any web-based application. Use stored procedures for database access When the database server supports them, use stored procedures for performing access on the application's behalf,which can eliminate SQL entirely (assuming the stored procedures themselves are written properly). By encapsulating the rules for a certain action - query, update, delete, etc. - into a single procedure, it can be tested anddocumented on a standalone basis and business rules enforced (for instance, the "add new order" procedure mightreject that order if the customer were over his credit limit). For simple queries this might be only a minor benefit, but as the operations become more complicated (or are used inmore than one place), having a single definition for the operation means it's going to be more robust and easier tomaintain. Note: it's always possible to write a stored procedure that itself constructs a query dynamically: this provides noprotection against SQL Injection - it's only proper binding with prepare/execute or direct SQL statements with boundvariables that provide this protection. Isolate the webserver Even having taken all these mitigation steps, it's nevertheless still possible to miss something and leave the server opento compromise. One ought to design the network infrastructure to assume that the bad guy will have full administratoraccess to the machine, and then attempt to limit how that can be leveraged to compromise other things. For instance, putting the machine in a DMZ with extremely limited pinholes "inside" the network means that even gettingcomplete control of the webserver doesn't automatically grant full access to everything else. This won't stop everything,of course, but it makes it a lot harder.


Configure error reporting The default error reporting for some frameworks includes developer debugging information, and this cannot be shown tooutside users. Imagine how much easier a time it makes for an attacker if the full query is shown, pointing to the syntaxerror involved. This information is useful to developers, but it should be restricted - if possible - to just internal users.

Affected items

Details

/bank/login.aspx

URL encoded POST input passw was set to 1'"Error message found: Syntax error in string in query expression


Content-Length: 33








Chrome/28.0.1500.63 Safari/537.36




Accept: */*

btnSubmit=Login&passw=1'%22&uid=1

Request headers



Pragma: no-cache


Expires: -1




Date: Thu, 16 Jul 2015 06:58:55 GMT

Connection: close


Response headers

Details

/bank/login.aspx

URL encoded POST input uid was set to 1'"Error message found: Syntax error in string in query expression


Content-Length: 48








Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers


btnSubmit=Login&passw=g00dPa%24%24w0rD&uid=1'%22



Pragma: no-cache


Expires: -1




Date: Thu, 16 Jul 2015 06:59:08 GMT

Connection: close


Response headers

Details

/subscribe.aspx

URL encoded POST input txtEmail was set to 1'"Error message found: Syntax error in string in query expression


Content-Length: 34








Chrome/28.0.1500.63 Safari/537.36




Accept: */*

btnSubmit=Subscribe&txtEmail=1'%22

Request headers



Pragma: no-cache


Expires: -1




Date: Thu, 16 Jul 2015 06:59:38 GMT

Connection: close


Response headers


Application error message

MediumSeverity

ValidationType

Scripting (Error_Message.script)Reported by module

Impact

Description

This page contains an error/warning message that may disclose sensitive information. The message can also contain thelocation of the file that produced the unhandled exception. This may be a false positive if the error message is found in documentation pages.

The error messages may disclose sensitive information. This information can be used to launch further attacks.

Recommendation

Review the source code for this script.

References

PHP Runtime Configuration

Affected items

Details

/bank/login.aspx

URL encoded POST input passw was set to 12345'"\'\");|]*{%0d%0a<%00>%bf%27'Error message found: System.Data.OleDb.OleDbException: Syntax error (missing operator) in query expression'username = '1' AND password = '12345'"\'\")'.


Content-Length: 63








Chrome/28.0.1500.63 Safari/537.36




Accept: */*

btnSubmit=Login&passw=12345'"\'\");|]*{%0d%0a<%00>%bf%27'&uid=1

Request headers



Pragma: no-cache


Expires: -1




Date: Thu, 16 Jul 2015 06:58:46 GMT

Connection: close


Response headers


http://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors

Details

/bank/login.aspx

URL encoded POST input uid was set to 12345'"\'\");|]*{%0d%0a<%00>%bf%27'Error message found: System.Data.OleDb.OleDbException: Syntax error (missing operator) in query expression'username = '12345'"\'\")'.


Content-Length: 78








Chrome/28.0.1500.63 Safari/537.36




Accept: */*

btnSubmit=Login&passw=g00dPa%24%24w0rD&uid=12345'"\'\");|]*{%0d%0a<%00>%bf%27'

Request headers



Pragma: no-cache


Expires: -1




Date: Thu, 16 Jul 2015 06:58:48 GMT

Connection: close


Response headers

Details

/subscribe.aspx

URL encoded POST input txtEmail was set to 12345'"\'\");|]*{%0d%0a<%00>%bf%27'Error message found: System.Data.OleDb.OleDbException: Syntax error (missing operator) in query expression''12345'"\'\"'.


Content-Length: 64








Chrome/28.0.1500.63 Safari/537.36




Accept: */*

btnSubmit=Subscribe&txtEmail=12345'"\'\");|]*{%0d%0a<%00>%bf%27'

Request headers



Pragma: no-cache


Expires: -1


Response headers




Date: Thu, 16 Jul 2015 06:59:06 GMT

Connection: close



Basic authentication over HTTP

MediumSeverity

ConfigurationType

Scripting (Basic_Auth_Over_HTTP.script)Reported by module

Impact

Description

In the context of an HTTP transaction, basic access authentication is a method for an HTTP user agent to provide a username and password when making a request. This directory is protected using Basic Authentication over an HTTP connection. With Basic Authentication the usercredentials are sent as cleartext and because HTTPS is not used, they are vulnerable to packet sniffing.

User credentials are sent as cleartext and are vulnerable to packet sniffing.

Recommendation

Use Basic Authentication over an HTTPS connection.

References

Basic access authentication

Affected items

Details

/bank/members/



http://en.wikipedia.org/wiki/Basic_access_authentication

Directory listing

MediumSeverity

InformationType

Scripting (Directory_Listing.script)Reported by module

Impact

Description

The web server is configured to display the list of files contained in this directory. This is not recommended because thedirectory may contain files that are not normally exposed through links on the web site.

A user can view a list of all files from this directory possibly exposing sensitive information.

Recommendation

You should make sure the directory does not contain sensitive information or you may want to restrict directory listingsfrom the web server configuration.

References

Directory Listing and Information Disclosure


How to disable directory listings - The easiest way to disable directory listing is to create an index file. The name of the index file depends on the webserver configuration. On Apache is called index.htm, index.html. On IIS is named default.asp, default.aspx, default.htm.- On IIS directory listings are disabled by default.- For Apache you need to edit the Apache configuration file (usually named httpd.conf) or create an .htaccess file. In theconfiguration file you will have the definition of the directory. Something like <Directory /directoryname/subdirectory>Options Indexes FollowSymLinks...</Directory>To disable directory listing for that directory you need to remove the 'Indexes' option.

Affected items

Details

/bank

Pattern found: <A HREF="/">[To Parent Directory]</A>

GET /bank/ HTTP/1.1

Pragma: no-cache


Referer: http://demo.testfire.net/bank/

Acunetix-Aspect: enabled

Acunetix-Aspect-Password: *****

Acunetix-Aspect-Queries: filelist;aspectalerts

Cookie: ASP.NET_SessionId=rx35k455p05mwieaeevyb445; amSessionId=15731163468





Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK

Content-Type: text/html; charset=UTF-8


Response headers


http://www.acunetix.com/blog/web-security-zone/directory-listing-information-disclosure/


Date: Thu, 16 Jul 2015 06:57:39 GMT


Details

/pr

Pattern found: <A HREF="/">[To Parent Directory]</A>

GET /pr/ HTTP/1.1

Pragma: no-cache


Referer: http://demo.testfire.net/pr/









Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK




Date: Thu, 16 Jul 2015 06:57:41 GMT

Content-Length: 517

Response headers


HTML form without CSRF protection

MediumSeverity

InformationalType

CrawlerReported by module

Impact

Description

This alert may be a false positive, manual confirmation is required.Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF or XSRF, is atype of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the websitetrusts. Acunetix WVS found a HTML form with no apparent CSRF protection implemented. Consult details for more informationabout the affected HTML form.

An attacker may force the users of a web application to execute actions of the attacker''s choosing. A successful CSRFexploit can compromise end user data and operation in case of normal user. If the targeted end user is the administratoraccount, this can compromise the entire web application.

Recommendation

Check if this form requires CSRF protection and implement CSRF countermeasures if necessary.

Affected items

Details

/

Form name: <empty>Form action: http://demo.testfire.net/search.aspxForm method: GET Form inputs: - txtSearch [Text]

GET / HTTP/1.1

Pragma: no-cache










Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Response headers


Date: Thu, 16 Jul 2015 06:57:33 GMT

Details

/bank/login.aspx

Form name: loginForm action: http://demo.testfire.net/bank/login.aspxForm method: POST Form inputs: - uid [Text]- passw [Password]- btnSubmit [Submit]

GET /bank/login.aspx HTTP/1.1

Pragma: no-cache


Referer: http://demo.testfire.net/









Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Date: Thu, 16 Jul 2015 06:57:36 GMT

Response headers

Details

/feedback.aspx

Form name: cmtForm action: http://demo.testfire.net/comment.aspxForm method: POST Form inputs: - cfile [Hidden]- name [Text]- email_addr [Text]- subject [Text]- comments [TextArea]- submit [Submit]

GET /feedback.aspx HTTP/1.1

Pragma: no-cache






Request headers







Chrome/28.0.1500.63 Safari/537.36




Accept: */*

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Date: Thu, 16 Jul 2015 06:57:36 GMT

Response headers

Details

/subscribe.aspx

Form name: subscribeForm action: http://demo.testfire.net/subscribe.aspxForm method: POST Form inputs: - txtEmail [Text]- btnSubmit [Submit]

GET /subscribe.aspx HTTP/1.1

Pragma: no-cache


Referer: http://demo.testfire.net/subscribe.swf









Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Date: Thu, 16 Jul 2015 06:57:40 GMT

Response headers


User credentials are sent in clear text

MediumSeverity

ConfigurationType


Impact

Description

User credentials are transmitted over an unencrypted channel. This information should always be transferred via anencrypted channel (HTTPS) to avoid being intercepted by malicious users.

A third party may be able to read the user credentials by intercepting an unencrypted HTTP connection.

Recommendation

Because user credentials are considered sensitive information, should always be transferred to the server over anencrypted connection (HTTPS).

Affected items

Details

/bank/login.aspx

Form name: loginForm action: http://demo.testfire.net/bank/login.aspxForm method: POST Form inputs: - uid [Text]- passw [Password]- btnSubmit [Submit]


Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Date: Thu, 16 Jul 2015 06:57:36 GMT

Response headers


ASP.NET debugging enabled

LowSeverity

ValidationType

Scripting (ASP-NET_Debugging_Enabled.script)Reported by module

Impact

Description

ASP.NET debugging is enabled on this application. It is recommended to disable debug mode before deploying aproduction application. By default, debugging is disabled, and although debugging is frequently enabled to troubleshoot aproblem, it is also frequently not disabled again after the problem is resolved.

It may be possible to disclose sensitive information about the web sever the ASP.NET application.

Recommendation

Check References for details on how to fix this problem.

References

HOW TO: Disable Debugging for ASP.NET Applications

Affected items

Details

/


DEBUG /acunetix_invalid_filename.aspx HTTP/1.1

Command: stop-debug






Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Content-Length: 2





Date: Thu, 16 Jul 2015 07:11:21 GMT

Response headers

Details

/bank


DEBUG /bank/acunetix_invalid_filename.aspx HTTP/1.1

Command: stop-debug






Chrome/28.0.1500.63 Safari/537.36


Request headers


http://support.microsoft.com/default.aspx?scid=kb;en-us;815157



Accept: */*

HTTP/1.1 200 OK


Content-Length: 2





Date: Thu, 16 Jul 2015 07:11:26 GMT

Response headers


Clickjacking: X-Frame-Options header missing

LowSeverity

ConfigurationType

Scripting (Clickjacking_X_Frame_Options.script)Reported by module

Impact

Description

Clickjacking (User Interface redress attack, UI redress attack, UI redressing) is a malicious technique of tricking a Webuser into clicking on something different from what the user perceives they are clicking on, thus potentially revealingconfidential information or taking control of their computer while clicking on seemingly innocuous web pages. The server didn't return an X-Frame-Options header which means that this website could be at risk of a clickjackingattack. The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should beallowed to render a page in a <frame> or <iframe>. Sites can use this to avoid clickjacking attacks, by ensuring that theircontent is not embedded into other sites.

The impact depends on the affected web application.

Recommendation

Configure your web server to include an X-Frame-Options header. Consult Web references for more information aboutthe possible values for this header.

References

Clickjacking

Original Clickjacking paper

The X-Frame-Options response header

Affected items

Details

Web Server


GET / HTTP/1.1






Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Date: Thu, 16 Jul 2015 06:57:33 GMT

Response headers


http://en.wikipedia.org/wiki/Clickjacking

http://www.sectheory.com/clickjacking.htm

https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options

Login page password-guessing attack

LowSeverity

ValidationType

Scripting (Html_Authentication_Audit.script)Reported by module

Impact

Description

A common threat web developers face is a password-guessing attack known as a brute force attack. A brute-force attackis an attempt to discover a password by systematically trying every possible combination of letters, numbers, andsymbols until you discover the one correct combination that works. This login page doesn't have any protection against password-guessing attacks (brute force attacks). It's recommendedto implement some type of account lockout after a defined number of incorrect password attempts. Consult Webreferences for more information about fixing this problem.

An attacker may attempt to discover a weak password by systematically trying every possible combination of letters,numbers, and symbols until it discovers the one correct combination that works.

Recommendation

It's recommended to implement some type of account lockout after a defined number of incorrect password attempts.

References

Blocking Brute Force Attacks

Affected items

Details

/bank/login.aspx

The scanner tested 10 invalid credentials and no account lockout was detected.


Content-Length: 43







Chrome/28.0.1500.63 Safari/537.36




Accept: */*

btnSubmit=Login&passw=RmFCk2Qy&uid=0RRo7K98

Request headers

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1



Set-Cookie: ASP.NET_SessionId=0kz1qgrv53cxgz45qoaa1hrv; path=/; HttpOnly

Set-Cookie: amSessionId=15853163765; path=/


Date: Thu, 16 Jul 2015 06:58:52 GMT

Response headers


http://www.owasp.org/index.php/Blocking_Brute_Force_Attacks

OPTIONS method is enabled

LowSeverity

ValidationType

Scripting (Options_Server_Method.script)Reported by module

Impact

Description

HTTP OPTIONS method is enabled on this web server. The OPTIONS method provides a list of the methods that aresupported by the web server, it represents a request for information about the communication options available on therequest/response chain identified by the Request-URI.

The OPTIONS method may expose sensitive information that may help an malicious user to prepare more advancedattacks.

Recommendation

It's recommended to disable OPTIONS Method on the web server.

References

Testing for HTTP Methods and XST (OWASP-CM-008)

Affected items

Details

Web Server

Methods allowed: OPTIONS, TRACE, GET, HEAD, POST

OPTIONS / HTTP/1.1






Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK

Allow: OPTIONS, TRACE, GET, HEAD, POST


Public: OPTIONS, TRACE, GET, HEAD, POST


Date: Thu, 16 Jul 2015 06:57:36 GMT

Content-Length: 0

Response headers


https://www.owasp.org/index.php/Testing_for_HTTP_Methods_and_XST_(OWASP-CM-008)

Possible sensitive directories

LowSeverity

ValidationType

Scripting (Possible_Sensitive_Directories.script)Reported by module

Impact

Description

A possible sensitive directory has been found. This directory is not directly linked from the website.This check looks forcommon sensitive resources like backup directories, database dumps, administration pages, temporary directories. Eachone of these directories could help an attacker to learn more about his target.

This directory may expose sensitive information that could help a malicious user to prepare more advanced attacks.

Recommendation

Restrict access to this directory or remove it from the website.

References

Web Server Security and Database Server Security

Affected items

Details

/admin


GET /admin HTTP/1.1

Accept: acunetix/wvs

Range: bytes=0-99999






Chrome/28.0.1500.63 Safari/537.36




Request headers

HTTP/1.1 301 Moved Permanently


Location: http://demo.testfire.net/admin/



Date: Thu, 16 Jul 2015 07:11:33 GMT

Content-Length: 154

Response headers


http://www.acunetix.com/websitesecurity/webserver-security.htm

Possible sensitive files

LowSeverity

ValidationType

Scripting (Possible_Sensitive_Files.script)Reported by module

Impact

Description

A possible sensitive file has been found. This file is not directly linked from the website. This check looks for commonsensitive resources like password files, configuration files, log files, include files, statistics data, database dumps. Eachone of these files could help an attacker to learn more about his target.

This file may expose sensitive information that could help a malicious user to prepare more advanced attacks.

Recommendation

Restrict access to this file or remove it from the website.

References

Web Server Security and Database Server Security

Affected items

Details

/test.aspx


GET /test.aspx HTTP/1.1

Accept: acunetix/wvs






Chrome/28.0.1500.63 Safari/537.36




Request headers

HTTP/1.1 200 OK


Content-Length: 558





Date: Thu, 16 Jul 2015 07:12:09 GMT

Response headers


http://www.acunetix.com/websitesecurity/webserver-security.htm

Session Cookie without HttpOnly flag set

LowSeverity

InformationalType


Impact

Description

This cookie does not have the HTTPOnly flag set. When a cookie is set with the HTTPOnly flag, it instructs the browserthat the cookie can only be accessed by the server and not by client-side scripts. This is an important security protectionfor session cookies.

None

Recommendation

If possible, you should set the HTTPOnly flag for this cookie.

Affected items

Details

/

Cookie name: "amSessionId"Cookie domain: "demo.testfire.net"

GET / HTTP/1.1






Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Date: Thu, 16 Jul 2015 06:57:33 GMT

Response headers

Details

/

Cookie name: "amCreditOffer"Cookie domain: "demo.testfire.net"

GET / HTTP/1.1






Chrome/28.0.1500.63 Safari/537.36


Request headers




Accept: */*

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Date: Thu, 16 Jul 2015 06:57:33 GMT

Response headers

Details

/

Cookie name: "amUserId"Cookie domain: "demo.testfire.net"

GET / HTTP/1.1






Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Date: Thu, 16 Jul 2015 06:57:33 GMT

Response headers

Details

/

Cookie name: "lang"Cookie domain: "demo.testfire.net"

GET / HTTP/1.1






Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Pragma: no-cache


Response headers



Expires: -1




Date: Thu, 16 Jul 2015 06:57:33 GMT


Session Cookie without Secure flag set

LowSeverity

InformationalType


Impact

Description

This cookie does not have the Secure flag set. When a cookie is set with the Secure flag, it instructs the browser that thecookie can only be accessed over secure SSL channels. This is an important security protection for session cookies.

None

Recommendation

If possible, you should set the Secure flag for this cookie.

Affected items

Details

/

Cookie name: "amUserId"Cookie domain: "demo.testfire.net"

GET / HTTP/1.1






Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Date: Thu, 16 Jul 2015 06:57:33 GMT

Response headers

Details

/

Cookie name: "amSessionId"Cookie domain: "demo.testfire.net"

GET / HTTP/1.1






Chrome/28.0.1500.63 Safari/537.36



Request headers



Accept: */*

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Date: Thu, 16 Jul 2015 06:57:33 GMT

Response headers

Details

/

Cookie name: "amCreditOffer"Cookie domain: "demo.testfire.net"

GET / HTTP/1.1






Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Date: Thu, 16 Jul 2015 06:57:33 GMT

Response headers

Details

/

Cookie name: "lang"Cookie domain: "demo.testfire.net"

GET / HTTP/1.1






Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Pragma: no-cache



Response headers


Expires: -1




Date: Thu, 16 Jul 2015 06:57:33 GMT

Details

/

Cookie name: "ASP.NET_SessionId"Cookie domain: "demo.testfire.net"

GET / HTTP/1.1






Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Date: Thu, 16 Jul 2015 06:57:33 GMT

Response headers


Broken links

InformationalSeverity

InformationalType


Impact

Description

A broken link refers to any link that should take you to a document, image or webpage, that actually results in an error.This page was linked from the website but it is inaccessible.

Problems navigating the site.

Recommendation

Remove the links to this file or make it accessible.

Affected items

Details

/bank/account.aspx.cs

For a complete list of URLs linking to this file, go to Site Structure > Locate and select the file (marked as "Not Found") >select Referrers Tab from the bottom of the Information pane.

GET /bank/account.aspx.cs HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers





Date: Thu, 16 Jul 2015 06:57:44 GMT

Connection: close


Response headers

Details

/bank/apply.aspx.cs


GET /bank/apply.aspx.cs HTTP/1.1

Pragma: no-cache





Request headers








Chrome/28.0.1500.63 Safari/537.36




Accept: */*





Date: Thu, 16 Jul 2015 06:57:43 GMT

Connection: close


Response headers

Details

/bank/bank.master


GET /bank/bank.master HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers





Date: Thu, 16 Jul 2015 06:57:43 GMT

Connection: close


Response headers

Details

/bank/bank.master.cs


GET /bank/bank.master.cs HTTP/1.1

Pragma: no-cache








Request headers





Chrome/28.0.1500.63 Safari/537.36




Accept: */*





Date: Thu, 16 Jul 2015 06:57:43 GMT

Connection: close


Response headers

Details

/bank/customize.aspx.cs


GET /bank/customize.aspx.cs HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers





Date: Thu, 16 Jul 2015 06:57:44 GMT

Connection: close


Response headers

Details

/bank/login.aspx.cs


GET /bank/login.aspx.cs HTTP/1.1

Pragma: no-cache











Request headers


Chrome/28.0.1500.63 Safari/537.36




Accept: */*





Date: Thu, 16 Jul 2015 06:57:43 GMT

Connection: close


Response headers

Details

/bank/logout.aspx.cs


GET /bank/logout.aspx.cs HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers





Date: Thu, 16 Jul 2015 06:57:43 GMT

Connection: close


Response headers

Details

/bank/main.aspx.cs


GET /bank/main.aspx.cs HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36



Request headers



Accept: */*





Date: Thu, 16 Jul 2015 06:57:43 GMT

Connection: close


Response headers

Details

/bank/queryxpath.aspx.cs


GET /bank/queryxpath.aspx.cs HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers





Date: Thu, 16 Jul 2015 06:57:44 GMT

Connection: close


Response headers

Details

/bank/transaction.aspx.cs


GET /bank/transaction.aspx.cs HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

Response headers






Date: Thu, 16 Jul 2015 06:57:44 GMT

Connection: close


Details

/bank/transfer.aspx.cs


GET /bank/transfer.aspx.cs HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers





Date: Thu, 16 Jul 2015 06:57:44 GMT

Connection: close


Response headers

Details

/inside_points_of_interest.htm


GET /inside_points_of_interest.htm HTTP/1.1

Pragma: no-cache


Referer: http://demo.testfire.net/default.aspx









Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers




Response headers



Date: Thu, 16 Jul 2015 06:57:38 GMT



Email address found


InformationalType

Scripting (Text_Search_File.script)Reported by module

Impact

Description

One or more email addresses have been found on this page. The majority of spam comes from email addressesharvested off the internet. The spam-bots (also known as email harvesters and email extractors) are programs that scourthe internet looking for email addresses on any website they come across. Spambot programs look for strings [email protected] and then record any addresses found.

Email addresses posted on Web sites may attract spam.

Recommendation

Check references for details on how to solve this problem.

References

Email Address Disclosed on Website Can be Used for Spam

Affected items

Details

/business_cards.htm

Pattern found: [email protected]

GET /business_cards.htm HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Last-Modified: Tue, 07 Jul 2015 10:14:20 GMT

Accept-Ranges: bytes

ETag: "2a9b47b09db8d01:0"



Date: Thu, 16 Jul 2015 07:17:42 GMT

Content-Length: 49

Response headers

Details

/cache.aspx


GET /cache.aspx HTTP/1.1

Pragma: no-cache

Request headers


http://www.websitedefender.com/web-security/email-address-disclosure/











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

HTTP/1.1 200 OK


Content-Length: 49





Date: Thu, 16 Jul 2015 07:17:42 GMT

Response headers

Details

/callback.aspx


GET /callback.aspx HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Content-Length: 49





Date: Thu, 16 Jul 2015 07:17:42 GMT

Response headers

Details

/files.aspx


GET /files.aspx HTTP/1.1

Pragma: no-cache




Request headers









Chrome/28.0.1500.63 Safari/537.36




Accept: */*

HTTP/1.1 200 OK


Content-Length: 49





Date: Thu, 16 Jul 2015 07:17:42 GMT

Response headers

Details

/header.aspx


GET /header.aspx HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Content-Length: 49





Date: Thu, 16 Jul 2015 07:17:42 GMT

Response headers

Details

/home.aspx


GET /home.aspx HTTP/1.1

Pragma: no-cache







Request headers






Chrome/28.0.1500.63 Safari/537.36




Accept: */*

HTTP/1.1 200 OK


Content-Length: 49





Date: Thu, 16 Jul 2015 07:17:42 GMT

Response headers

Details

/index.aspx


GET /index.aspx HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Content-Length: 49





Date: Thu, 16 Jul 2015 07:17:42 GMT

Response headers

Details

/info.aspx


GET /info.aspx HTTP/1.1

Pragma: no-cache










Request headers



Chrome/28.0.1500.63 Safari/537.36




Accept: */*

HTTP/1.1 200 OK


Content-Length: 49





Date: Thu, 16 Jul 2015 07:17:42 GMT

Response headers

Details

/inside_about.htm


GET /inside_about.htm HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK




ETag: "c9acab5f9db8d01:0"



Date: Thu, 16 Jul 2015 07:17:42 GMT

Content-Length: 49

Response headers

Details

/inside_investor.htm


GET /inside_investor.htm HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36

Request headers





Accept: */*

HTTP/1.1 200 OK




ETag: "6bf554609db8d01:0"



Date: Thu, 16 Jul 2015 07:17:42 GMT

Content-Length: 49

Response headers

Details

/log.aspx


GET /log.aspx HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Content-Length: 49





Date: Thu, 16 Jul 2015 07:17:42 GMT

Response headers

Details

/login.aspx


GET /login.aspx HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36



Request headers



Accept: */*

HTTP/1.1 200 OK


Content-Length: 49





Date: Thu, 16 Jul 2015 07:17:42 GMT

Response headers

Details

/orders.aspx


GET /orders.aspx HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Content-Length: 49





Date: Thu, 16 Jul 2015 07:17:42 GMT

Response headers

Details

/robots.txt


GET /robots.txt HTTP/1.1

Pragma: no-cache










Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

Response headers


HTTP/1.1 200 OK

Content-Type: text/plain



ETag: "33a33b7a9db8d01:0"



Date: Thu, 16 Jul 2015 06:57:34 GMT

Content-Length: 49

Details

/security.htm


GET /security.htm HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK




ETag: "10c892339eb8d01:0"



Date: Thu, 16 Jul 2015 07:17:42 GMT

Content-Length: 49

Response headers

Details

/signup.aspx


GET /signup.aspx HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK

Response headers



Content-Length: 49





Date: Thu, 16 Jul 2015 07:17:42 GMT


GHDB: Typical login page


InformationalType

GHDBReported by module

Impact

Description

The description for this alert is contributed by the GHDB community, it may contain inappropriate language.Category : Pages containing login portals This is a typical login page. It has recently become a target for SQL injection. Comsec's article athttp://www.governmentsecurity.org/articles/SQLinjectionBasicTutorial.php brought this to my attention. The Google Hacking Database (GHDB) appears courtesy of the Google Hacking community.

Not available. Check description.

Recommendation

Not available. Check description.

References

The Google Hacking Database (GHDB) community

Acunetix Google hacking

Affected items

Details

/bank/login.aspx

We found inurl:login.asp


Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Date: Thu, 16 Jul 2015 06:57:36 GMT

Response headers


http://johnny.ihackstuff.com/

http://www.acunetix.com/websitesecurity/google-hacking.htm

Details

/bank/login.aspx (825f8b5076aa7df703fc45c8fed863e5)



Pragma: no-cache


Referer: http://demo.testfire.net/bank/login.aspx

Content-Length: 44










Chrome/28.0.1500.63 Safari/537.36




Accept: */*

btnSubmit=Login&passw=g00dPa%24%24w0rD&uid=1

Request headers

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Date: Thu, 16 Jul 2015 06:57:39 GMT

Response headers

Details

/bank/login.aspx.cs


GET /bank/login.aspx.cs HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers





Date: Thu, 16 Jul 2015 06:57:43 GMT

Response headers


Connection: close


Details

/login.aspx


GET /login.aspx HTTP/1.1

Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Content-Length: 49





Date: Thu, 16 Jul 2015 07:17:42 GMT

Response headers


Password type input with auto-complete enabled


InformationalType


Impact

Description

When a new name and password is entered in a form and the form is submitted, the browser asks if the passwordshould be saved.Thereafter when the form is displayed, the name and password are filled in automatically or arecompleted as the name is entered. An attacker with local access could obtain the cleartext password from the browsercache.

Possible sensitive information disclosure.

Recommendation

The password auto-complete should be disabled in sensitive applications. To disable auto-complete, you may use a code similar to: <INPUT TYPE="password" AUTOCOMPLETE="off">

Affected items

Details

/bank/login.aspx

Password type input named passw from form named login with action login.aspx has autocomplete enabled.


Pragma: no-cache











Chrome/28.0.1500.63 Safari/537.36




Accept: */*

Request headers

HTTP/1.1 200 OK


Pragma: no-cache



Expires: -1




Date: Thu, 16 Jul 2015 06:57:36 GMT

Response headers


Scanned items (coverage report)

Scanned 61 URLs. Found 39 vulnerable.

Vulnerabilities has been identified for this URL

URL: http://demo.testfire.net/

6 input(s) found for this URL

Inputs

Input scheme 1

Input name Input type

/ Path Fragment (suffix .aspx)


Input scheme 2



Input scheme 3


/ Path Fragment (suffix /)

Input scheme 4


/ Path Fragment (suffix .htm)

Input scheme 5


Host HTTP Header


URL: http://demo.testfire.net/search.aspx


Inputs

Input scheme 1


txtSearch URL encoded GET

No vulnerabilities has been identified for this URL

URL: http://demo.testfire.net/style.css

No input(s) found for this URL


URL: http://demo.testfire.net/default.aspx


Inputs

Input scheme 1


content URL encoded GET


URL: http://demo.testfire.net/feedback.aspx



URL: http://demo.testfire.net/bank/




URL: http://demo.testfire.net/bank/login.aspx


Inputs

Input scheme 1


btnSubmit URL encoded POST

passw URL encoded POST

uid URL encoded POST


URL: http://demo.testfire.net/bank/ws.asmx


Inputs

Input scheme 1


op URL encoded GET

Input scheme 2


URL encoded GET


URL: http://demo.testfire.net/bank/members/



URL: http://demo.testfire.net/bank/main.aspx



URL: http://demo.testfire.net/bank/apply.aspx



URL: http://demo.testfire.net/bank/logout.aspx



URL: http://demo.testfire.net/bank/mozxpath.js



URL: http://demo.testfire.net/bank/bank.master



URL: http://demo.testfire.net/bank/login.aspx.cs



URL: http://demo.testfire.net/bank/20060308_bak/



URL: http://demo.testfire.net/bank/main.aspx.cs




URL: http://demo.testfire.net/bank/account.aspx



URL: http://demo.testfire.net/bank/transfer.aspx



URL: http://demo.testfire.net/bank/apply.aspx.cs



URL: http://demo.testfire.net/bank/bank.master.cs



URL: http://demo.testfire.net/bank/customize.aspx



URL: http://demo.testfire.net/bank/logout.aspx.cs



URL: http://demo.testfire.net/bank/account.aspx.cs



URL: http://demo.testfire.net/bank/queryxpath.aspx



URL: http://demo.testfire.net/bank/transfer.aspx.cs



URL: http://demo.testfire.net/bank/transaction.aspx



URL: http://demo.testfire.net/bank/servererror.aspx



URL: http://demo.testfire.net/bank/customize.aspx.cs



URL: http://demo.testfire.net/bank/queryxpath.aspx.cs



URL: http://demo.testfire.net/bank/transaction.aspx.cs



URL: http://demo.testfire.net/images/




URL: http://demo.testfire.net/survey_questions.aspx


Inputs

Input scheme 1


step URL encoded GET


URL: http://demo.testfire.net/robots.txt



URL: http://demo.testfire.net/subscribe.swf



URL: http://demo.testfire.net/disclaimer.htm


Inputs

Input scheme 1


url URL encoded GET


URL: http://demo.testfire.net/inside_points_of_interest.htm



URL: http://demo.testfire.net/pr/



URL: http://demo.testfire.net/pr/docs.xml



URL: http://demo.testfire.net/retirement.htm



URL: http://demo.testfire.net/comment.aspx


Inputs

Input scheme 1


cfile URL encoded POST

comments URL encoded POST

email_addr URL encoded POST

name URL encoded POST

subject URL encoded POST

submit URL encoded POST


URL: http://demo.testfire.net/subscribe.aspx


Inputs


Input scheme 1


btnSubmit URL encoded POST

txtEmail URL encoded POST


URL: http://demo.testfire.net/comments.txt



URL: http://demo.testfire.net/inside_about.htm



URL: http://demo.testfire.net/inside_investor.htm



URL: http://demo.testfire.net/business_cards.htm



URL: http://demo.testfire.net/security.htm



URL: http://demo.testfire.net/admin/



URL: http://demo.testfire.net/test.aspx



URL: http://demo.testfire.net/cache.aspx



URL: http://demo.testfire.net/callback.aspx



URL: http://demo.testfire.net/files.aspx



URL: http://demo.testfire.net/header.aspx



URL: http://demo.testfire.net/home.aspx



URL: http://demo.testfire.net/index.aspx



URL: http://demo.testfire.net/info.aspx




URL: http://demo.testfire.net/log.aspx



URL: http://demo.testfire.net/login.aspx



URL: http://demo.testfire.net/orders.aspx



URL: http://demo.testfire.net/signup.aspx



URL: http://demo.testfire.net/static/



Documents

Executive Report