OWASP - User contributions [en]

Insecure Configuration Management

2006-10-26T21:24:37Z

Jewel: linkify reference to other top ten entry

==Description==

Web server and application server configurations play a key role in the security of a web application. These servers are responsible for serving content and invoking applications that generate content. In addition, many application servers provide a number of services that web applications can use, including data storage, directory services, mail, messaging, and more. Failure to manage the proper configuration of your servers can lead to a wide variety of security problems.

Frequently, the web development group is separate from the group operating the site. In fact, there is often a wide gap between those who write the application and those responsible for the operations environment. Web application security concerns often span this gap and require members from both sides of the project to properly ensure the security of a site’s application.

There are a wide variety of server configuration problems that can plague the security of a site. These include:

* Unpatched security flaws in the server software
* Server software flaws or misconfigurations that permit directory listing and directory traversal attacks
* Unnecessary default, backup, or sample files, including scripts, applications, configuration files, and web pages
* Improper file and directory permissions
* Unnecessary services enabled, including content management and remote administration
* Default accounts with their default passwords
* Administrative or debugging functions that are enabled or accessible
* Overly informative error messages (more details in the [[Improper Error Handling|error handling section]])
* Misconfigured SSL certificates and encryption settings
* Use of self-signed certificates to achieve authentication and man-in-the-middle protection
* Use of default certificates
* Improper authentication with external systems

Some of these problems can be detected with readily available security scanning tools. Once detected, these problems can be easily exploited and result in total compromise of a website. Successful attacks can also result in the compromise of backend systems including databases and corporate networks. Having secure software and a secure configuration are both required in order to have a secure site.

==Environments Affected==

All web servers, application servers, and web application environments are susceptible to misconfiguration.

==Examples and References==

* [[:Category:OWASP_Guide_Project|OWASP Guide]] to Building Secure Web Applications and Web Services
* Web Server Security Best Practices: http://www.pcmag.com/article2/0,4149,11525,00.asp
* Securing Public Web Servers (from CERT): http://www.cert.org/security-improvement/modules/m11.html

==How to Determine If You Are Vulnerable==

If you have not made a concerted effort to lock down your web and application servers you are most likely vulnerable. Few, if any, server products are secure out of the box. A secure configuration for your platform should be documented and updated frequently. A manual review of the configuration guide should be performed regularly to ensure that it has been kept up to date and is consistent. A comparison to the actual deployed systems is also recommended.

In addition, there are a number of scanning products available that will externally scan a web or application server for known vulnerabilities, including Nessus and Nikto. You should run these tools on a regular basis, at least monthly, to find problems as soon as possible. The tools should be run both internally and externally. External scans should be run from a host located external to the server’s network. Internal scans should be run from the same network as the target servers.

==How to Protect Yourself==

The first step is to create a hardening guideline for your particular web server and application server configuration. This configuration should be used on all hosts running the application and in the development environment as well. We recommend starting with any existing guidance you can find from your vendor or those available from the various existing security organizations such as OWASP, CERT, and SANS and then tailoring them for your particular needs. The hardening guideline should include the following topics:

* Configuring all security mechanisms
* Turning off all unused services
* Setting up roles, permissions, and accounts, including disabling all default accounts or changing their passwords
* Logging and alerts

Once your guideline has been established, use it to configure and maintain your servers. If you have a large number of servers to configure, consider semi-automating or completely automating the configuration process. Use an existing configuration tool or develop your own. A number of such tools already exist. You can also use disk replication tools such as Ghost to take an image of an existing hardened server, and then replicate that image to new servers. Such a process may or may not work for you given your particular environment.

Keeping the server configuration secure requires vigilance. You should be sure that the responsibility for keeping the server configuration up to date is assigned to an individual or team. The maintenance process should include:

* Monitoring the latest security vulnerabilities published
* Applying the latest security patches
* Updating the security configuration guideline
* Regular vulnerability scanning from both internal and external perspectives
* Regular internal reviews of the server’s security configuration as compared to your configuration guide
* Regular status reports to upper management documenting overall security posture

[[Category:OWASP Top Ten Project]]

__NOEDITSECTION__

Cross Site Scripting Flaw

2006-10-26T21:06:40Z

Jewel: Replace image with table and fix encodings

==Description==
Cross-site scripting (sometimes referred to as XSS) vulnerabilities occur when an attacker uses a web application to send malicious code, generally in the form of a script, to a different end user. These flaws are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating it.

An attacker can use cross site scripting to send malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page.

XSS attacks can generally be categorized into two categories: stored and reflected. Stored attacks are those where the injected code is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Reflected attacks are those where the injected code is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web server. When a user is tricked into clicking on a malicious link or submitting a specially crafted form, the injected code travels to the vulnerable web server, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a ‘trusted’ server.

The consequence of an XSS attack is the same regardless of whether it is stored or reflected. The difference is in how the payload arrives at the server. Do not be fooled into thinking that a “read only” or “brochureware” site is not vulnerable to serious reflected XSS attacks. XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. The most severe XSS attacks involve disclosure of the user’s session cookie, allowing an attacker to hijack the user’s session and take over the account. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirecting the user to some other page or site, and modifying presentation of content. An XSS vulnerability allowing an attacker to modify a press release or news item could affect a company’s stock price or lessen consumer confidence. An XSS vulnerability on a pharmaceutical site could allow an attacker to modify dosage information resulting in an overdose.

Attackers frequently use a variety of methods to encode the malicious portion of the tag, such as using Unicode, so the request is less suspicious looking to the user. There are hundreds of variants of these attacks, including versions that do not even require any < > symbols. For this reason, attempting to “filter out” these scripts is not likely to succeed. Instead we recommend validating input against a rigorous positive specification of what is expected. XSS attacks usually come in the form of embedded JavaScript. However, any embedded active content is a potential source of danger, including: ActiveX (OLE), VBscript, Shockwave, Flash and more.

XSS issues can also be present in the underlying web and application servers as well. Most web and application servers generate simple web pages to display in the case of various errors, such as a 404 ‘page not found’ or a 500 ‘internal server error.’ If these pages reflect back any information from the user’s request, such as the URL they were trying to access, they may be vulnerable to a reflected XSS attack.

The likelihood that a site contains XSS vulnerabilities is extremely high. There are a wide variety of ways to trick web applications into relaying malicious scripts. Developers that attempt to filter out the malicious parts of these requests are very likely to overlook possible attacks or encodings. Finding these flaws is not tremendously difficult for attackers, as all they need is a browser and some time. There are numerous free tools available that help hackers find these flaws as well as carefully craft and inject XSS attacks into a target site.

==Environments Affected==

All web servers, application servers, and web application environments are susceptible to cross site scripting.

==Examples and References==
* The Cross Site Scripting FAQ: http://www.cgisecurity.com/articles/xss-faq.shtml
* XSS Cheat Sheet: http://ha.ckers.org/xss.html
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html
* CERT “Understanding Malicious Content Mitigation” http://www.cert.org/tech_tips/malicious_code_mitigation.html
* Cross-Site Scripting Security Exposure Executive Summary: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/topics/ExSumCS.asp
* Understanding the cause and effect of CSS Vulnerabilities: http://www.technicalinfo.net/papers/CSS.html
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: Data Validation http://www.owasp.org/documentation/guide.html
* How to Build an HTTP Request Validation Engine (J2EE validation with Stinger) http://www.owasp.org/columns/jeffwilliams/jeffwilliams2
* Have Your Cake and Eat it Too (.NET validation) http://www.owasp.org/columns/jpoteet/jpoteet2

==How to Determine If You Are Vulnerable==
XSS flaws can be difficult to identify and remove from a web application. The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output. Note that a variety of different HTML tags can be used to transmit a malicious JavaScript. Nessus, Nikto, and some other available tools can help scan a website for these flaws, but can only scratch the surface. If one part of a website is vulnerable, there is a high likelihood that there are other problems as well.

==How to Protect Yourself==

The best way to protect a web application from XSS attacks is ensure that your application performs validation of all headers, cookies, query strings, form fields, and hidden fields (i.e., all parameters) against a rigorous specification of what should be allowed. The validation should not attempt to identify active content and remove, filter, or sanitize it. There are too many types of active content and too many ways of encoding it to get around filters for such content. We strongly recommend a ‘positive’ security policy that specifies what is allowed. ‘Negative’ or attack signature based policies are difficult to maintain and are likely to be incomplete.

Encoding user supplied output can also defeat XSS vulnerabilities by preventing inserted scripts from being transmitted to users in an executable form. Applications can gain significant protection from javascript based attacks by converting the following characters in all generated output to the appropriate HTML entity encoding:

{| border="1"
|+ HTML Entities
! Character !! Encoding
|-
| < || &lt; or &#60;
|-
| > || &gt; or &#62;
|-
| & || &amp; or &#38;
|-
| " || &quot; or &#34;
|-
| ' || &#39;
|-
| ( || &#40;
|-
| ) || &#41;
|-
| # || &#35;
|-
| % || &#37;
|-
| ; || &#59;
|-
| + || &#43;
|-
| - || &#45;
|}

The [[:Category:OWASP Filters Project|OWASP Filters project]] is producing reusable components in several languages to help prevent many forms of parameter tampering, including the injection of XSS attacks. OWASP has also released [[OWASP CodeSeeker Project|CodeSeeker]], an application level firewall. In addition, the [[:Category:OWASP WebGoat Project|OWASP WebGoat Project]] training program has lessons on Cross Site Scripting and data encoding.

==Categories==

[[Category:OWASP Top Ten Project]]
[[Category:Vulnerability]]

__NOEDITSECTION__