A CRLF (New line) injection in HTTP headers was identified. This means that the input goes into HTTP headers without proper input filtering.
Impact
Depending on the application. An attacker might carry out the following forms of attacks:
Cross-site Scripting attack which can lead to session hijacking
Session fixation attack by setting a new cookie, which can again lead to session hijacking
Actions to Take
See the remedy for solution.
Ensure the server security patches are up to date and that the current stable version of the software is in use.
Remedy
Do not allow newline characters in input. Where possible use strict white listing.
Required Skills for Successful Exploitation
Crafting the attack to exploit this issue is not a complex process. However most of the unsophisticated attackers will not know that such an attack is possible. Also an attacker needs to reach his victim by an e-mail or other similar method in order to entice them to visit the site or click upon a URL.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>302 Found</title></head><body><h1>Found</h1><p>The document has moved <a href="http://example.com/?">here</a>.</p></body></html>
Netsparker identified Open Policy Crossdomain.xml file.
Impact
Open Policy Crossdomain.xml file allows other SWF files to make HTTP requests to your web server and see its response. This can be used for accessing one time tokens and CSRF nonces to bypass CSRF restrictions.
Remedy
Configure your Crossdomain.xml to prevent access from everywhere to your domain.
Netsparker identified Open Policy Clientaccesspolicy.xml file.
Impact
Open Policy Clientaccesspolicy.xml file allows other Silverlight client services to make HTTP requests to your web server and see its response. This might be used for accessing one time tokens and CSRF nonces to bypass CSRF restrictions.
Remedy
Configure your Clientaccesspolicy.xml to prevent access from everywhere to your domain.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>302 Found</title></head><body><h1>Found</h1><p>The document has moved <a href="http://www.netsparker.com?">here</a>.</p></body></html>
XSS (Cross-site Scripting) allows an attacker to execute a dynamic script (Javascript, VbScript) in the context of the application. This allows several different attack opportunities, mostly hijacking the current session of the user or changing the look of the page by changing the HTML on the fly to steal the user's credentials. This happens because the input entered by a user has been interpreted as HTML/Javascript/VbScript by the browser.
Netsparker believes that there is a XSS (Cross-site Scripting) in here it could not confirm it. We strongly recommend investigating the issue manually to ensure that it is an XSS (Cross-site Scripting) and needs to be addressed.
XSS targets the users of the application instead of the server. Although this is a limitation, since it allows attackers to hijack other users' session, an attacker might attack an administrator to gain full control over the application.
Impact
There are many different attacks that can be leveraged through the use of XSS, including:
Hi-jacking users' active session
Changing the look of the page within the victims browser.
Mounting a successful phishing attack.
Intercept data and perform man-in-the-middle attacks.
Remedy
The issue occurs because the browser interprets the input as active HTML, Javascript or VbScript. To avoid this, all input and output from the application should be filtered / encoded. Output should be filtered / encoded according to the output format and location.
There are a number of pre-defined, well structured white-list libraries available for many different environments, good examples of these include, OWASP Reform and Microsoft Anti Cross-site Scripting libraries are good examples.
Due to content-type of the response exploitation of this vulnerability might not be possible in all browsers or might not be possible at all. Content-type indicates that there is a possibility of exploitation by changing the attack however Netsparker does not support confirming these issues. You need to manually confirm this problem. Generally lack of filtering in the response can cause Cross-site Scripting vulnerabilities in browsers with auto mime sniffing such as Internet Explorer.
Due to content-type of the response exploitation of this vulnerability might not be possible in all browsers or might not be possible at all. Content-type indicates that there is a possibility of exploitation by changing the attack however Netsparker does not support confirming these issues. You need to manually confirm this problem. Generally lack of filtering in the response can cause Cross-site Scripting vulnerabilities in browsers with auto mime sniffing such as Internet Explorer.
Due to content-type of the response exploitation of this vulnerability might not be possible in all browsers or might not be possible at all. Content-type indicates that there is a possibility of exploitation by changing the attack however Netsparker does not support confirming these issues. You need to manually confirm this problem. Generally lack of filtering in the response can cause Cross-site Scripting vulnerabilities in browsers with auto mime sniffing such as Internet Explorer.
Due to content-type of the response exploitation of this vulnerability might not be possible in all browsers or might not be possible at all. Content-type indicates that there is a possibility of exploitation by changing the attack however Netsparker does not support confirming these issues. You need to manually confirm this problem. Generally lack of filtering in the response can cause Cross-site Scripting vulnerabilities in browsers with auto mime sniffing such as Internet Explorer.
The Server responded with an HTTP status 500. This indicates that there is a server-side error. Reasons may vary. The behavior should be analysed carefully. If Netsparker is able to find a security issue in the same resource it will report this as a separate vulnerability.
Impact
The impact may vary depending on the condition. Generally this indicates poor coding practices, not enough error checking, sanitization and whitelisting. However there might be a bigger issue such as SQL Injection. If that's the case Netsparker will check for other possible issues and report them separately.
Remedy
Analyse this issue and review the application code in order to handle unexpected errors, this should be a generic practice which does not disclose further information upon an error. All errors should be handled server side only.
HTTP/1.1 500 Internal Server Error Date: Tue, 03 May 2011 01:01:47 GMT Server: Apache Content-Length: 536 Connection: close Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>500 Internal Server Error</title></head><body><h1>Internal Server Error</h1><p>The server encountered an internal error ormisconfiguration and was unable to completeyour request.</p><p>Please contact the server administrator, root@weborama.fr and inform them of the time the error occurred,and anything you might have done that may havecaused the error.</p><p>More information about this error may be availablein the server error log.</p></body></html>
Cookie was not marked as HTTPOnly. HTTPOnly cookies can not be read by client-side scripts therefore marking a cookie as HTTPOnly can provide an additional layer of protection against Cross-site Scripting attacks..
Impact
During a Cross-site Scripting attack an attacker might easily access cookies and hijack the victim's session.
Actions to Take
See the remedy for solution
Consider marking all of the cookies used by the application as HTTPOnly (After these changes javascript code will not able to read cookies.
Remedy
Mark the cookie as HTTPOnly. This will be an extra layer of defence against XSS. However this is not a silver bullet and will not protect the system against Cross-site Scripting attacks. An attacker can use a tool such as XSS Tunnel to bypass HTTPOnly protection.
GET /fcgi-bin/adserv.fcgi?tag=496052&f=2149&ef=1&clicktag=%5BURLTRACKING%5D13256991'%20or%201=1--%20&rnd=%5BRANDOM%5D HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Cache-Control: no-cache Host: ieo.solution.weborama.fr Accept-Encoding: gzip, deflate Connection: Keep-Alive
Response
HTTP/1.1 302 Found Date: Tue, 03 May 2011 01:01:30 GMT Server: Apache P3P: CP="NOI DSP COR CURa DEVa PSAa OUR STP UNI DEM" Set-Cookie: AFFICHE_W=aMwQewJQu79n34;expires=Thu, 02 May 2013 01:01:30 GMT;domain=.weborama.fr;path=/ Location: http://ieo.solution.weborama.fr/fcgi-bin/adserv.fcgi?tag=496052&f=2149&ef=1&BOUNCE=OK&brnd=43621&clicktag=%5BURLTRACKING%5D13256991'%20or%201=1--%20&rnd=%5BRANDOM%5D Content-Length: 373 Connection: close Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>302 Found</title></head><body><h1>Found</h1><p>The document has moved <a href="http://ieo.solution.weborama.fr/fcgi-bin/adserv.fcgi?tag=496052&f=2149&ef=1&BOUNCE=OK&brnd=43621&clicktag=%5BURLTRACKING%5D13256991'%20or%201=1--%20&rnd=%5BRANDOM%5D">here</a>.</p></body></html>
Netsparker identified that the TRACE/TRACK method is allowed.
Impact
If the application is vulnerable to Cross-site Scripting and uses Http-Only Cookies then an attacker can bypass the Http-Only cookies limitation and read the cookies in an XSS attack.
Remedy
Disable this method in all production systems. Even though the application is not vulnerable to Cross-site Scripting a debugging feature such as TRACE/TRACK should not be required in a production system and therefore should be disabled.
GET /fcgi-bin/ HTTP/1.1 Referer: http://ieo.solution.weborama.fr/fcgi-bin/adserv.fcgi?tag=496052&f=2149&ef=1&clicktag=%5BURLTRACKING%5D13256991'%20or%201=1--%20&rnd=%5BRANDOM%5D User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Cache-Control: no-cache Host: ieo.solution.weborama.fr Accept-Encoding: gzip, deflate Connection: Keep-Alive
Response
HTTP/1.1 403 Forbidden Date: Tue, 03 May 2011 01:01:30 GMT Server: Apache Content-Length: 211 Connection: close Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>403 Forbidden</title></head><body><h1>Forbidden</h1><p>You don't have permission to access /fcgi-bin/on this server.</p></body></html>
Netsparker found e-mail addresses on the web site.
Impact
E-mail addresses discovered within the application can be used by both spam email engines and also brute force tools. Furthermore valid email addresses may lead to social engineering attacks .
Remedy
Use generic email addresses such as contact@ or info@ for general communications, remove user/people specific e-mail addresses from the web site, should this be required use submission forms for this purpose.
HTTP/1.1 500 Internal Server Error Date: Tue, 03 May 2011 01:01:47 GMT Server: Apache Content-Length: 536 Connection: close Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>500 Internal Server Error</title></head><body><h1>Internal Server Error</h1><p>The server encountered an internal error ormisconfiguration and was unable to completeyour request.</p><p>Please contact the server administrator, root@weborama.fr and inform them of the time the error occurred,and anything you might have done that may havecaused the error.</p><p>More information about this error may be availablein the server error log.</p></body></html>
