<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
		<id>https://wiki.owasp.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Cturra</id>
		<title>OWASP - User contributions [en]</title>
		<link rel="self" type="application/atom+xml" href="https://wiki.owasp.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Cturra"/>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php/Special:Contributions/Cturra"/>
		<updated>2026-05-22T15:20:38Z</updated>
		<subtitle>User contributions</subtitle>
		<generator>MediaWiki 1.27.2</generator>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Vancouver&amp;diff=130515</id>
		<title>Vancouver</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Vancouver&amp;diff=130515"/>
				<updated>2012-05-24T18:48:40Z</updated>
		
		<summary type="html">&lt;p&gt;Cturra: /* 2012 Meetings */ added may 2012 meeting&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Chapter Template|chaptername=Vancouver|extra=The chapter leader is Yvan Boily (yvanboily at gmail.com).&lt;br /&gt;
|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-vancouver|emailarchives=http://lists.owasp.org/pipermail/owasp-vancouver}}&lt;br /&gt;
&lt;br /&gt;
== 2012 Meetings ==&lt;br /&gt;
You can subscribe to the OWASP Vancouver Calendar [https://www.google.com/calendar/ical/osgb36r55fqlt3m10jc4e2ef70%40group.calendar.google.com/public/basic.ics here].&lt;br /&gt;
&lt;br /&gt;
=== May 2012 ===&lt;br /&gt;
&lt;br /&gt;
'''OAuth-based single sign-on in Real-world Implementations'''&lt;br /&gt;
&lt;br /&gt;
'''Speaker:''' San-Tsai Sung&lt;br /&gt;
&lt;br /&gt;
'''Date &amp;amp; Time:''' Monday, May 28th, 2012 @ 5:30pm&lt;br /&gt;
&lt;br /&gt;
Millions of web users today employ their Facebook accounts to sign into more than one million relying party (RP) websites. This web-based&lt;br /&gt;
single sign-on (SSO) scheme is enabled by OAuth 2.0, a web resource authorization protocol that has been adopted by major service providers. The OAuth 2.0 protocol has proven secure by several formal methods, but whether it is indeed secure in practice remains an open&lt;br /&gt;
question. We examine the implementations of three major OAuth identity providers (IdP) (Facebook, Microsoft, and Google) and 96 popular RP&lt;br /&gt;
websites that support the use of Facebook accounts for login.  Our results uncover several critical vulnerabilities that allow an attacker to gain unauthorized access to the victim user's profile and social graph, and impersonate the victim on the RP website. Closer&lt;br /&gt;
examination reveals that these vulnerabilities are caused by a set of design decisions that trade security for implementation simplicity. To improve the security of OAuth 2.0 SSO systems in real-world settings, we suggest simple and practical improvements to the design and implementation of IdPs and RPs that can be adopted gradually by individual sites.&lt;br /&gt;
&lt;br /&gt;
'''Registration:''' Registration is strongly recommended since an invite will be extended to other groups to try to improve participation in OWASP. If space runs out, preference will be given to those who have registered!&lt;br /&gt;
&lt;br /&gt;
Please register at: [https://docs.google.com/spreadsheet/viewform?formkey=dHZSeTY1ZnFKTFo1elBRZ3BsenNvRnc6MQ here].&lt;br /&gt;
''(Registration details are not retained after the meeting, however a sign-up sheet will be available for those claiming CPEs)''&lt;br /&gt;
&lt;br /&gt;
'''Location:''' &lt;br /&gt;
Mozilla Vancouver, Suite 209, 163 West Hastings,&lt;br /&gt;
Vancouver, BC (Buzzer code is in the directory)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== January 2012 ===&lt;br /&gt;
&lt;br /&gt;
'''Outsourcing Identity: Understanding Privacy and Security in Identity Services'''&lt;br /&gt;
&lt;br /&gt;
'''Speaker:''' Yvan Boily, Web Security Engineer, Mozilla Corporation&lt;br /&gt;
&lt;br /&gt;
'''Date &amp;amp; Time:''' Monday, January 23rd, 2012 @ 5:30pm&lt;br /&gt;
&lt;br /&gt;
Social Media has taken over the online world; what Microsoft attempted with Passport has been made reality by Facebook, Twitter, Google, and other service providers.  In addition to the proprietary identity services these platforms offer, several support protocols such as OpenID, This will be a one hour presentation that will contrast the security and privacy features available in major online identity protocols, and contrast these with Mozilla's BrowserID protocol.&lt;br /&gt;
&lt;br /&gt;
'''Registration:'''  Registration is strongly recommended since an invite will be extended to other groups to try to improve participation in OWASP.  If space runs out, preference will be given to those who have registered!&lt;br /&gt;
&lt;br /&gt;
Please register [https://docs.google.com/spreadsheet/viewform?formkey=dHZSeTY1ZnFKTFo1elBRZ3BsenNvRnc6MQ here].&lt;br /&gt;
''(Registration details are not retained after the meeting, however a sign-up sheet will be available for those claiming CPEs)''&lt;br /&gt;
&lt;br /&gt;
'''Location:'''&lt;br /&gt;
Ping Identity,&lt;br /&gt;
200 - 788 Beatty St,&lt;br /&gt;
Vancouver&lt;br /&gt;
&lt;br /&gt;
'''About Ping Identity&lt;br /&gt;
'''&lt;br /&gt;
Ping Identity has generously offered their downtown office space, located on the corner of Beatty and Robson, to host our chapters meetings moving forward. The office is 6000sq/ft of a mostly open floor plan, so we should be able to accommodate a large group.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Category:British Columbia]]&lt;/div&gt;</summary>
		<author><name>Cturra</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=User:Cturra&amp;diff=125697</id>
		<title>User:Cturra</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=User:Cturra&amp;diff=125697"/>
				<updated>2012-03-07T06:35:03Z</updated>
		
		<summary type="html">&lt;p&gt;Cturra: updates!&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==About Me==&lt;br /&gt;
DevOpsSec.&lt;br /&gt;
&lt;br /&gt;
==Contact==&lt;br /&gt;
more contact info? I trust you can find it yourself :P&lt;/div&gt;</summary>
		<author><name>Cturra</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Vancouver&amp;diff=18906</id>
		<title>Vancouver</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Vancouver&amp;diff=18906"/>
				<updated>2007-06-01T02:33:26Z</updated>
		
		<summary type="html">&lt;p&gt;Cturra: added minutes from last chapter meeting&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Chapter Template|chaptername=Vancouver|extra=The chapter leader is [mailto:nrerup@pdbsec.com Neil Rerup]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-vancouver|emailarchives=http://lists.owasp.org/pipermail/owasp-vancouver}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Last OWASP Chapter Meeting May 30th 5:30pm - 7:00pm==&lt;br /&gt;
'''Attendance:'''&lt;br /&gt;
* Neil (PDB Security)&lt;br /&gt;
* Chris (Sxip Identity)&lt;br /&gt;
* Mauro (Business Objects)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Introdcutions'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''' Ideas for new members?'''&lt;br /&gt;
* Chris to lead web page&lt;br /&gt;
* Mauro to contact other local security groups (ISACA, ISSA, CIPS Security Special Interest Group)&lt;br /&gt;
* Neil to arrange speakers&lt;br /&gt;
* Group to invite friends :)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Future Speakers'''&lt;br /&gt;
* Topics of interest: fuzzing, risk modeling (CLASP), other risk methodologies, cryptography, web services, tools&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Other ideas?'''&lt;br /&gt;
* Goals of the chatper: grow, crosponation of ideas in app. sec. space, evangilize app sec! &lt;br /&gt;
* Chatted about compliance standards.&lt;br /&gt;
* Chatted about info sec. vs app. sec. as a whole.&lt;/div&gt;</summary>
		<author><name>Cturra</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=LDAP_injection&amp;diff=9509</id>
		<title>LDAP injection</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=LDAP_injection&amp;diff=9509"/>
				<updated>2006-09-06T18:20:59Z</updated>
		
		<summary type="html">&lt;p&gt;Cturra: Initial content&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Template:Attack}}&lt;br /&gt;
&lt;br /&gt;
==Description==&lt;br /&gt;
LDAP (Lightweight Directory Access Protocol) Injection is an attack used to exploit web based applications by constructing LDAP statements from user input. When an application fails to sufficiently sanatize user input, it may be possible for an attacker to alter the construction of an LDAP statement. Due to the nature of web based applicationthe process will be run with the same permissions as the web server itself. Thus this could result in the execution of the command. Such a scenario could result in granting permissions to query, modify or remove anything inside the LDAP tree.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
*[http://www.ietf.org/rfc/rfc1960.txt A String Representation of LDAP Search Filters (RFC1960)]&lt;br /&gt;
*[http://www.redbooks.ibm.com/redbooks/SG244986.html IBM RedBooks - Understanding LDAP]&lt;br /&gt;
&lt;br /&gt;
==Related Attacks==&lt;br /&gt;
*[[Interpreter Injection]]&lt;br /&gt;
*[[SQL Injection]]&lt;br /&gt;
*[[Command Injection]]&lt;br /&gt;
&lt;br /&gt;
==Related Vulnerabilities==&lt;br /&gt;
[[:Category:Lack of Input Validation]]&lt;br /&gt;
&lt;br /&gt;
==Related Countermeasures==&lt;br /&gt;
[[:Category:Input Validation]]&lt;br /&gt;
&lt;br /&gt;
==Categories==&lt;br /&gt;
[[Category:Injection Attack]]&lt;/div&gt;</summary>
		<author><name>Cturra</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Blind_SQL_Injection&amp;diff=9375</id>
		<title>Blind SQL Injection</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Blind_SQL_Injection&amp;diff=9375"/>
				<updated>2006-08-30T22:42:26Z</updated>
		
		<summary type="html">&lt;p&gt;Cturra: Added more categories&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Template:Attack}}&lt;br /&gt;
&lt;br /&gt;
==Description==&lt;br /&gt;
Blind SQL injection is identical to normal [http://www.owasp.org/index.php/SQL_injection SQL injection], however, when such an attack is performed a handled error message is returned. This results in no generic database error messages and without disclosing such information the attacker is working '&amp;lt;i&amp;gt;blindly&amp;lt;/i&amp;gt;.'&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Online Resources'''&lt;br /&gt;
* [http://www.ngssoftware.com/papers/more_advanced_sql_injection.pdf more Advanced SQL Injection] - by NGS&lt;br /&gt;
* [http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-hotchkies/bh-us-04-hotchkies.pdf Blind SQL Injection Automation Techniques] - Black Hat Pdf&lt;br /&gt;
* [http://seclists.org/lists/bugtraq/2005/Feb/0288.html Blind Sql-Injection in MySQL Databases]&lt;br /&gt;
* [http://www.cgisecurity.com/questions/blindsql.shtml Cgisecurity.com: What is Blind SQL Injection?]&lt;br /&gt;
* [http://www.securitydocs.com/library/2651 Blind SQL Injection]&lt;br /&gt;
* http://www.spidynamics.com/whitepapers/Blind_SQLInjection.pdf&lt;br /&gt;
* http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html&lt;br /&gt;
* [http://wcsc.myweb.usf.edu/tutorials/SQL_Injection.ppt SQL Injection Attacks]&lt;br /&gt;
&lt;br /&gt;
'''Tools'''&lt;br /&gt;
* [http://www.sqlpowerinjector.com/ SQL Power Injector]&lt;br /&gt;
* [http://www.0x90.org/releases/absinthe/ [Absinthe :: Automated Blind SQL Injection] // ver1.3.1&lt;br /&gt;
* [http://www.securiteam.com/tools/5IP0L20I0E.html SQLBrute - Multi Threaded Blind SQL Injection Bruteforcer] in Python&lt;br /&gt;
* [http://www.owasp.org/index.php/Category:OWASP_SQLiX_Project SQLiX - SQL Injection Scanner] in Perl&lt;br /&gt;
&lt;br /&gt;
==Examples ==&lt;br /&gt;
&lt;br /&gt;
==Related Threats==&lt;br /&gt;
&lt;br /&gt;
==Related Attacks==&lt;br /&gt;
&lt;br /&gt;
==Related Problems==&lt;br /&gt;
* [[Injection problem]]&lt;br /&gt;
&lt;br /&gt;
==Related Countermeasures==&lt;br /&gt;
&lt;br /&gt;
==Categories==&lt;br /&gt;
[[Category:Attack]]&lt;br /&gt;
[[Category:Injection Attack]]&lt;br /&gt;
[[Category:OWASP_CLASP_Project]]&lt;br /&gt;
[[Category:OWASP_SQLiX_Project]]&lt;br /&gt;
[[Category:Code Snippet]]&lt;br /&gt;
[[Category:Java]]&lt;br /&gt;
[[Category:SQL]]&lt;/div&gt;</summary>
		<author><name>Cturra</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Blind_SQL_Injection&amp;diff=9374</id>
		<title>Blind SQL Injection</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Blind_SQL_Injection&amp;diff=9374"/>
				<updated>2006-08-30T22:41:26Z</updated>
		
		<summary type="html">&lt;p&gt;Cturra: Added cross-reference to Injection Problems&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Template:Attack}}&lt;br /&gt;
&lt;br /&gt;
==Description==&lt;br /&gt;
Blind SQL injection is identical to normal [http://www.owasp.org/index.php/SQL_injection SQL injection], however, when such an attack is performed a handled error message is returned. This results in no generic database error messages and without disclosing such information the attacker is working '&amp;lt;i&amp;gt;blindly&amp;lt;/i&amp;gt;.'&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Online Resources'''&lt;br /&gt;
* [http://www.ngssoftware.com/papers/more_advanced_sql_injection.pdf more Advanced SQL Injection] - by NGS&lt;br /&gt;
* [http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-hotchkies/bh-us-04-hotchkies.pdf Blind SQL Injection Automation Techniques] - Black Hat Pdf&lt;br /&gt;
* [http://seclists.org/lists/bugtraq/2005/Feb/0288.html Blind Sql-Injection in MySQL Databases]&lt;br /&gt;
* [http://www.cgisecurity.com/questions/blindsql.shtml Cgisecurity.com: What is Blind SQL Injection?]&lt;br /&gt;
* [http://www.securitydocs.com/library/2651 Blind SQL Injection]&lt;br /&gt;
* http://www.spidynamics.com/whitepapers/Blind_SQLInjection.pdf&lt;br /&gt;
* http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html&lt;br /&gt;
* [http://wcsc.myweb.usf.edu/tutorials/SQL_Injection.ppt SQL Injection Attacks]&lt;br /&gt;
&lt;br /&gt;
'''Tools'''&lt;br /&gt;
* [http://www.sqlpowerinjector.com/ SQL Power Injector]&lt;br /&gt;
* [http://www.0x90.org/releases/absinthe/ [Absinthe :: Automated Blind SQL Injection] // ver1.3.1&lt;br /&gt;
* [http://www.securiteam.com/tools/5IP0L20I0E.html SQLBrute - Multi Threaded Blind SQL Injection Bruteforcer] in Python&lt;br /&gt;
* [http://www.owasp.org/index.php/Category:OWASP_SQLiX_Project SQLiX - SQL Injection Scanner] in Perl&lt;br /&gt;
&lt;br /&gt;
==Examples ==&lt;br /&gt;
&lt;br /&gt;
==Related Threats==&lt;br /&gt;
&lt;br /&gt;
==Related Attacks==&lt;br /&gt;
&lt;br /&gt;
==Related Problems==&lt;br /&gt;
* [[Injection problem]]&lt;br /&gt;
&lt;br /&gt;
==Related Countermeasures==&lt;br /&gt;
&lt;br /&gt;
==Categories==&lt;br /&gt;
&lt;br /&gt;
{{Template:Stub}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Injection Attack]]&lt;br /&gt;
[[Category:OWASP SQLiX Project]]&lt;/div&gt;</summary>
		<author><name>Cturra</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Blind_SQL_Injection&amp;diff=9373</id>
		<title>Blind SQL Injection</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Blind_SQL_Injection&amp;diff=9373"/>
				<updated>2006-08-30T22:40:10Z</updated>
		
		<summary type="html">&lt;p&gt;Cturra: Added text description&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Template:Attack}}&lt;br /&gt;
&lt;br /&gt;
==Description==&lt;br /&gt;
Blind SQL injection is identical to normal [http://www.owasp.org/index.php/SQL_injection SQL injection], however, when such an attack is performed a handled error message is returned. This results in no generic database error messages and without disclosing such information the attacker is working '&amp;lt;i&amp;gt;blindly&amp;lt;/i&amp;gt;.'&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Online Resources'''&lt;br /&gt;
* [http://www.ngssoftware.com/papers/more_advanced_sql_injection.pdf more Advanced SQL Injection] - by NGS&lt;br /&gt;
* [http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-hotchkies/bh-us-04-hotchkies.pdf Blind SQL Injection Automation Techniques] - Black Hat Pdf&lt;br /&gt;
* [http://seclists.org/lists/bugtraq/2005/Feb/0288.html Blind Sql-Injection in MySQL Databases]&lt;br /&gt;
* [http://www.cgisecurity.com/questions/blindsql.shtml Cgisecurity.com: What is Blind SQL Injection?]&lt;br /&gt;
* [http://www.securitydocs.com/library/2651 Blind SQL Injection]&lt;br /&gt;
* http://www.spidynamics.com/whitepapers/Blind_SQLInjection.pdf&lt;br /&gt;
* http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html&lt;br /&gt;
* [http://wcsc.myweb.usf.edu/tutorials/SQL_Injection.ppt SQL Injection Attacks]&lt;br /&gt;
&lt;br /&gt;
'''Tools'''&lt;br /&gt;
* [http://www.sqlpowerinjector.com/ SQL Power Injector]&lt;br /&gt;
* [http://www.0x90.org/releases/absinthe/ [Absinthe :: Automated Blind SQL Injection] // ver1.3.1&lt;br /&gt;
* [http://www.securiteam.com/tools/5IP0L20I0E.html SQLBrute - Multi Threaded Blind SQL Injection Bruteforcer] in Python&lt;br /&gt;
* [http://www.owasp.org/index.php/Category:OWASP_SQLiX_Project SQLiX - SQL Injection Scanner] in Perl&lt;br /&gt;
&lt;br /&gt;
==Examples ==&lt;br /&gt;
&lt;br /&gt;
==Related Threats==&lt;br /&gt;
&lt;br /&gt;
==Related Attacks==&lt;br /&gt;
&lt;br /&gt;
==Related Vulnerabilities==&lt;br /&gt;
&lt;br /&gt;
==Related Countermeasures==&lt;br /&gt;
&lt;br /&gt;
==Categories==&lt;br /&gt;
&lt;br /&gt;
{{Template:Stub}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Injection Attack]]&lt;br /&gt;
[[Category:OWASP SQLiX Project]]&lt;/div&gt;</summary>
		<author><name>Cturra</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Category:Path_Traversal_Attack&amp;diff=9144</id>
		<title>Category:Path Traversal Attack</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Category:Path_Traversal_Attack&amp;diff=9144"/>
				<updated>2006-08-18T22:50:48Z</updated>
		
		<summary type="html">&lt;p&gt;Cturra: Initial content&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Description==&lt;br /&gt;
A Path Transversal attack is the technique in which one forces access to directories, files and or commands that can cause some adverse effect on the web server. This can be accomplished by attacking either the server or application level. &lt;br /&gt;
&lt;br /&gt;
==Examples==&lt;br /&gt;
The most basic Path Transversal attack uses the '../' special character sequence to alter the location of the request. In an Operating System, this special character combination notes to move down one directory. An example of such an attack could look like the following: http://foo.com/../../barfile&lt;br /&gt;
&lt;br /&gt;
While the web server may stand up well to such an attack, another approach is to target the application itself. Most commonly the use of parameters being passed by the application can be exploited. Such data can come from user input or application data being passed between pages. Let's take for the following example into account: http://foo.com/bar.cgi?store=mystore.html&lt;br /&gt;
&lt;br /&gt;
We can observe from the above that bar.cgi takes a parameter to navigate through the application; in this case, the store location is mystore.html. We can use this knowledge to attempt the retrieval of bar.cgi's source code by submitting: http://foo.com/bar.cgi?store=bar.cgi&lt;br /&gt;
&lt;br /&gt;
This can be taken a step further. By combining the two methods above one may be able to retrieve server resident content using the application as a means of accessing it. Keep in mind, the web server daemon (process) runs as a user on the machine and as such the application has read access to certain areas. Using the foobar store example URL above, let look at how we can grab a file from another location of the server: http://foo.com/bar.cgi?../../secretfile.txt &lt;br /&gt;
&lt;br /&gt;
==Categories==&lt;br /&gt;
[[Category:Attack]]&lt;/div&gt;</summary>
		<author><name>Cturra</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=CRLF_Injection&amp;diff=9134</id>
		<title>CRLF Injection</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=CRLF_Injection&amp;diff=9134"/>
				<updated>2006-08-17T23:08:02Z</updated>
		
		<summary type="html">&lt;p&gt;Cturra: Initial content&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Template:Vulnerability}}&lt;br /&gt;
&lt;br /&gt;
==Description==&lt;br /&gt;
The term CRLF refers to '''C'''arage '''R'''eturn (ASCII 13, \r) '''L'''ine '''F'''eed (ASCII 10, \n). They're used to note the termination of a line, however, dealt with differently in today’s popular Operating Systems. For example: in Windows both a CR and LF are required to note the end of a line, whereas in Linux/UNIX a LF is only required.&lt;br /&gt;
&lt;br /&gt;
A CFLR Injection attack occurs when a user managed to submit a CRLF into an application. This is most commonly done by modifying an HTTP parameter or URL. &lt;br /&gt;
&lt;br /&gt;
==Impact and Example==&lt;br /&gt;
Depending on how the application is developed this can be a minor problem or a fairly serious security flaw. Lets look at the latter because this is after all a security related post. &lt;br /&gt;
&lt;br /&gt;
Lets assume a file is used at some point to read/write data to -likely a log of some sort. If an attacker managed to place a CRLF then can then inject some sort of read programmatic method to the file. This could result in the contents being written to screen on the next attempt to use this file. &lt;br /&gt;
&lt;br /&gt;
==Categories==&lt;br /&gt;
[[Category:Vulnerability]]&lt;br /&gt;
[[Category:Implementation]]&lt;/div&gt;</summary>
		<author><name>Cturra</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Glossary&amp;diff=7250</id>
		<title>Glossary</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Glossary&amp;diff=7250"/>
				<updated>2006-07-13T15:42:44Z</updated>
		
		<summary type="html">&lt;p&gt;Cturra: Additional glossary term: ISO/IEC 17799&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{compactTOC}}&lt;br /&gt;
&lt;br /&gt;
{{SecureSoftware}}&lt;br /&gt;
&lt;br /&gt;
==0–9==&lt;br /&gt;
===3DES===&lt;br /&gt;
See also: [[#Triple DES|Triple DES]]&lt;br /&gt;
==A==&lt;br /&gt;
===Access Control List===&lt;br /&gt;
A list of credentials attached to a resource indicating whether or not the credentials have access to the resource.&lt;br /&gt;
===ACL===&lt;br /&gt;
Access Control List&lt;br /&gt;
===Active attack===&lt;br /&gt;
Any network-based attack other than simple eavesdropping — i.e., a passive attack).&lt;br /&gt;
===Advanced Encryption Standard===&lt;br /&gt;
A fast general-purpose block cipher standardized by NIST (the National Institute of Standards and Technology). The AES selection process was a multi-year competition, where Rijndael was the winning cipher.&lt;br /&gt;
===AES===&lt;br /&gt;
See also: [[#Advanced Encryption Standard|Advanced Encryption Standard]]&lt;br /&gt;
===Anti-debugger===&lt;br /&gt;
Referring to technology that detects or thwarts the use of a debugger on a piece of software.&lt;br /&gt;
===Anti-tampering===&lt;br /&gt;
Referring to technology that attempts to thwart the reverse engineering and patching of a piece of software in binary format.&lt;br /&gt;
===Architectural security assessment===&lt;br /&gt;
See also: [[#Threat model|Threat Model]]&lt;br /&gt;
&lt;br /&gt;
===ASN.1===&lt;br /&gt;
Abstract Syntax Notation is a language for representing data objects. It is popular to use this in specifying cryptographic protocols, usually using DER (Distinguished Encoding Rules), which allows the data layout to be unambiguously specified.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Distinguished Encoding Rules|Distinguished Encoding Rules]].&lt;br /&gt;
===Asymmetric cryptography===&lt;br /&gt;
Cryptography involving public keys, as opposed to cryptography making use of shared secrets.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Symmetric cryptography|Symmetric cryptography]].&lt;br /&gt;
===Audit===&lt;br /&gt;
In the context of security, a review of a system in order to validate the security of the system. Generally, this either refers to code auditing or reviewing audit logs.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Audit log|Audit log]], [[#Code auditing|Code auditing]].&lt;br /&gt;
===Audit log===&lt;br /&gt;
Records that are kept for the purpose of later verifying that the security properties of a system have remained intact.&lt;br /&gt;
===Authenticate-and-encrypt===&lt;br /&gt;
When using a cipher to encrypt and a MAC to provide message integrity, this paradigm specifies that one authenticates the plaintext and encrypts the plaintext, possibly in parallel. This is not secure in the general case.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Authenticate-then-encrypt|Authenticate-then-encrypt]], [[#Encrypt-then-authenticate|Encrypt-then-authenticate]].&lt;br /&gt;
&lt;br /&gt;
===Authenticate-then-encrypt===&lt;br /&gt;
When using a cipher to encrypt and a MAC to provide message integrity, this paradigm specifies that one authenticates the plaintext and then encrypts the plaintext concatenated with the MAC tag. This is not secure in the general case, but usually works well in practice.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Authenticate-and-encrypt|Authenticate-and-encrypt]], [[#Encrypt-then-authenticate|Encrypt-then-authenticate]].&lt;br /&gt;
===Authentication===&lt;br /&gt;
The process of verifying identity, ownership, and/or authorization.&lt;br /&gt;
==B==&lt;br /&gt;
===Backdoor===&lt;br /&gt;
Malicious code inserted into a program for the purposes of providing the author covert access to machines running the program.&lt;br /&gt;
===Base 64===&lt;br /&gt;
encoding A method for encoding binary data into printable ASCII strings. Every byte of output maps to six bits of input (minus possible padding bytes).&lt;br /&gt;
===Big endian===&lt;br /&gt;
Refers to machines representing words most significant byte first. While x86 machines do not use big endian byte ordering (instead using little endian), the PowerPC and SPARC architectures do. This is also network byte order.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Little endian|Little endian]].&lt;br /&gt;
===Birthday attack===&lt;br /&gt;
Take a function f() that seems to map an input to a random output of some fixed size (a pseudo-random function or PRF). A birthday attack is simply selecting random inputs for f() and checking to see if any previous values gave the same output. Statistically, if the output size is S bits, then one can find a collision in 2S/2 operations, on average.&lt;br /&gt;
===Bit-flipping attack===&lt;br /&gt;
In a stream cipher, flipping a bit in the ciphertext flips the corresponding bit in the plaintext. If using a message authentication code (MAC), such attacks are not practical.&lt;br /&gt;
===Blacklist=== When performing input validation, the set of items that — if matched — result in the input being considered invalid. If no invalid items are found, the result is valid.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Whitelist|Whitelist]].&lt;br /&gt;
&lt;br /&gt;
===Blinding===&lt;br /&gt;
A technique used to thwart timing attacks.&lt;br /&gt;
===Block cipher===&lt;br /&gt;
An encryption algorithm that maps inputs of size n to outputs of size n (n is called the block size). Data that is not a valid block size must somehow be padded (generally by using an encryption mode). The same input always produces the same output.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Stream cipher|Stream cipher]].&lt;br /&gt;
===Blowfish===&lt;br /&gt;
A block cipher with 64-bit blocks and variable length keys, created by Bruce Schneier. This cipher is infamous for having slow key-setup times.&lt;br /&gt;
===Brute-force attack===&lt;br /&gt;
An attack on an encryption algorithm where the encryption key for a ciphertext is determined by trying to decrypt with every key until valid plaintext is obtained.&lt;br /&gt;
===Buffer overflow===&lt;br /&gt;
A buffer overflow is when you can put more data into a memory location than is allocated to hold that data. Languages like C and C++ that do no built-in bounds checking are susceptible to such problems. These problems are often security-critical.&lt;br /&gt;
==C==&lt;br /&gt;
===CA===&lt;br /&gt;
See Certification Authority.&lt;br /&gt;
===Canary===&lt;br /&gt;
A piece of data, the absence of which indicates a violation of a security policy. Several tools use a canary for preventing certain stack-smashing buffer overflow attacks.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Buffer overflow|Buffer overflow]], [[#Stack smashing|Stack smashing]].&lt;br /&gt;
===Capture-replay attacks===&lt;br /&gt;
When an attacker can capture data off the wire and replay it later without the bogus data being detected as bogus.&lt;br /&gt;
===Carter-Wegmen Counter (data encryption mode)===&lt;br /&gt;
A parallelizable and patent-free high-level encryption mode that provides both encryption and built-in message integrity.&lt;br /&gt;
&lt;br /&gt;
===CAST5===&lt;br /&gt;
A block cipher with 64-bit blocks and key sizes up to 128 bits. It is patent- free, and generally considered sound, but modern algorithms with larger block sizes are generally preferred (e.g., AES). &lt;br /&gt;
&lt;br /&gt;
See also: [[#AES|AES]].&lt;br /&gt;
===CBC Mode===&lt;br /&gt;
See also: [[#Cipher-Block Chaining mode|Cipher-Block Chaining mode]].&lt;br /&gt;
&lt;br /&gt;
===CBC-MAC===&lt;br /&gt;
A simple construction for turning a block cipher into a message authentication code. It only is secure when all messages MAC’d with a single key are the same size. However, there are several variants that thwart this problem, the most important being OMAC. &lt;br /&gt;
&lt;br /&gt;
See also: [[#OMAC|OMAC]].&lt;br /&gt;
===CCM mode===&lt;br /&gt;
See also: [[#Counter mode with CBC-MAC (CCM)|Counter mode with CBC-MAC (CCM)]].&lt;br /&gt;
&lt;br /&gt;
===Certificate===&lt;br /&gt;
A data object that binds information about a person or some other entity to a public key. The binding is generally done using a digital signature from a trusted third party (a certification authority).&lt;br /&gt;
===Certificate Revocation List===&lt;br /&gt;
A list published by a certification authority indicating which issued certificates should be considered invalid.&lt;br /&gt;
===Certificate Signing Request===&lt;br /&gt;
Data about an entity given to a certification authority. The authority will package the data into a certificate and sign the certificate if the data in the signing request is validated.&lt;br /&gt;
===Certification Authority===&lt;br /&gt;
An entity that manages digital certificates — i.e., issues and revokes. Verisign and InstantSSL are two well known CAs.&lt;br /&gt;
===CFB mode===&lt;br /&gt;
See also: [[#Cipher Feedback mode|Cipher Feedback mode]].&lt;br /&gt;
===Chain responder===&lt;br /&gt;
An OCSP responder that relays the results of querying another OCSP responder.&lt;br /&gt;
&lt;br /&gt;
See also: [[#OCSP|OCSP]].&lt;br /&gt;
&lt;br /&gt;
===Choke point===&lt;br /&gt;
In computer security, a place in a system where input is routed for the purposes of performing data validation. The implication is that there are few such places in a system and that all data must pass through one or more of the choke points. The idea is that funneling input through a small number of choke points makes it easier to ensure that input is properly validated. One potential concern is that poorly chosen choke points may not have enough information to perform input validation that is as accurate as possible.&lt;br /&gt;
===chroot===&lt;br /&gt;
A UNIX system call that sets the root directory for a process to any arbitrary directory. The idea is compartmentalization: Even if a process is compromised, it should not be able to see interesting parts of the file system beyond its own little world. There are some instances where chroot &amp;amp;quot;jails&amp;amp;quot; can be circumvented; it can be difficult to build proper operating environments to make chroot work well.&lt;br /&gt;
===Cipher-Block Chaining mode===&lt;br /&gt;
A block cipher mode that provides secrecy but not message integrity. Messages encrypted with this mode should have random initialization vectors.&lt;br /&gt;
===Cipher Feedback mode===&lt;br /&gt;
A mode that turns a block cipher into a stream cipher. This mode is safe only when used in particular configurations. Generally, CTR mode and OFB mode are used instead since both have better security bounds.&lt;br /&gt;
===Ciphertext===&lt;br /&gt;
The result of encrypting a message.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Plaintext|Plaintext]].&lt;br /&gt;
===Ciphertext stealing mode===&lt;br /&gt;
A block cipher mode of operation that is similar to CBC mode except that the final block is processed in such a way that the output is always the same length as the input. That is, this mode is similar to CBC mode but does not require padding.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Cipher-Block Chaining mode|Cipher-Block Chaining mode]], [[#Padding|Padding]].&lt;br /&gt;
&lt;br /&gt;
===CLASP===&lt;br /&gt;
See also: [[#Comprehesive, Lightweight Application Security Process|Comprehesive, Lightweight Application Security Process]]&lt;br /&gt;
&lt;br /&gt;
===Code auditing===&lt;br /&gt;
Reviewing computer software for security problems.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Audit|Audit]].&lt;br /&gt;
===Code signing===&lt;br /&gt;
Signing executable code to establish that it comes from a trustworthy vendor. The signature must be validated using a trusted third party in order to establish identity.&lt;br /&gt;
===Compartmentalization===&lt;br /&gt;
Separating a system into parts with distinct boundaries, using simple, well- defined interfaces. The basic idea is that of containment — i.e., if one part is compromised, perhaps the extent of the damage can be limited.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Jail|Jail]], [[#Chroot|Chroot]].&lt;br /&gt;
===Comprehesive, Lightweight Application Security Process===&lt;br /&gt;
An activity-driven, role based set of process components whose core contains formalized best practices for building security into your existing or new-start software development lifecycles in a structured, repeatable, and measurable way.&lt;br /&gt;
&lt;br /&gt;
See also:&lt;br /&gt;
* [[:Category:OWASP CLASP Project|OWASP CLASP Project]]&lt;br /&gt;
&lt;br /&gt;
===Context object===&lt;br /&gt;
In a cryptographic library, a data object that holds the intermediate state associated with the cryptographic processing of a piece of data. For example, if incrementally hashing a string, a context object stores the internal state of the hash function necessary to process further data.&lt;br /&gt;
===Counter mode===&lt;br /&gt;
A parallelizable encryption mode that effectively turns a block cipher into a stream cipher. It is a popular component in authenticated encryption schemes due to its optimal security bounds and good performance characteristics.&lt;br /&gt;
===Counter mode with CBC-MAC (CCM)===&lt;br /&gt;
An encryption mode that provides both message secrecy and integrity. It was the first such mode that was not covered by patent.&lt;br /&gt;
&lt;br /&gt;
===CRAM===&lt;br /&gt;
A password-based authentication mechanism using a cryptographic hash function (usually MD5). It does not provide adequate protection against several common threats to password-based authentication systems. HTTP Digest Authentication is a somewhat better alternative; it is replacing CRAM in most places.&lt;br /&gt;
===CRC===&lt;br /&gt;
Cyclic Redundancy Check. A means of determining whether accidental transmission errors have occurred. Such algorithms are not cryptographically secure because attackers can often forge CRC values or even modify data maliciously in such a way that the CRC value does not change. Instead, one should use a strong, keyed message authentication code such as HMAC or OMAC.&lt;br /&gt;
&lt;br /&gt;
See also: [[#HMAC|HMAC]], [[#Message Authentication Code|Message Authentication Code]], [[#OMAC|OMAC]].&lt;br /&gt;
===Critical extensions===&lt;br /&gt;
In an X.509 certificate, those extensions that must be recognized by any software processing the certificate. If a piece of software does not recognize an extension marked as critical, the software must regard the certificate as invalid.&lt;br /&gt;
===CRL===&lt;br /&gt;
See also: [[#Certificate Revocation List|Certificate Revocation List]].&lt;br /&gt;
===Cross-site scripting===&lt;br /&gt;
A class of problems resulting from insufficient input validation where one user can add content to a web site that can be malicious when viewed by other users to the web site. For example, one might post to a message board that accepts arbitrary HTML and include a malicious code item.&lt;br /&gt;
===Cryptanalysis===&lt;br /&gt;
The science of breaking cryptographic algorithms.&lt;br /&gt;
===Cryptographic hash function===&lt;br /&gt;
A function that takes an input string of arbitrary length and produces a fixed- size output — where it is unfeasible to find two inputs that map to the same output, and it is unfeasible to learn anything about the input from the output.&lt;br /&gt;
===Cryptographic randomness===&lt;br /&gt;
Data produced by a cryptographic pseudo-random number generator. The probability of figuring out the internal state of the generator is related to the strength of the underlying cryptography — i.e., assuming the generator is seeded with enough entropy.&lt;br /&gt;
===Cryptography===&lt;br /&gt;
The science of providing secrecy, integrity, and non-repudiation for data.&lt;br /&gt;
===CSR===&lt;br /&gt;
See also: [[#Certificate Signing Request|Certificate Signing Request]].&lt;br /&gt;
===CSS===&lt;br /&gt;
Cross-site scripting. Generally, however, this is abbreviated to XSS in order to avoid confusion with cascading style sheets.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Cross-site scripting|Cross-site scripting]].&lt;br /&gt;
===CTR mode===&lt;br /&gt;
See also: [[#Counter mode|Counter mode]].&lt;br /&gt;
===CWC mode===&lt;br /&gt;
See also: [[#Carter-Wegmen Counter (data encryption mode)|Carter Wegmen + Counter mode]].&lt;br /&gt;
&lt;br /&gt;
==D==&lt;br /&gt;
===DACL===&lt;br /&gt;
Discretionary Access Control List. In a Windows ACL, a list that determines access rights to an object.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Access Control List|Access Control List]].&lt;br /&gt;
&lt;br /&gt;
===Davies-Meyer===&lt;br /&gt;
An algorithm for turning a block cipher into a cryptographic one-way hash function.&lt;br /&gt;
===Default deny===&lt;br /&gt;
A paradigm for access control and input validation where an action must explicitly be allowed. The idea behind this paradigm is that one should limit the possibilities for unexpected behavior by being strict, instead of lenient, with rules.&lt;br /&gt;
===Defense-in-depth===&lt;br /&gt;
A principle for building systems stating that multiple defensive mechanisms at different layers of a system are usually more secure than a single layer of defense. For example, when performing input validation, one might validate user data as it comes in and then also validate it before each use — just in case something was not caught, or the underlying components are linked against a different front end, etc.&lt;br /&gt;
===DEK===&lt;br /&gt;
Data encrypting key.&lt;br /&gt;
===Delta CRLs===&lt;br /&gt;
A variation of Certificate Revocation Lists that allows for incremental updating, as an effort to avoid frequently re-downloading a large amount of unchanged data.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Certificate Revocation List|Certificate Revocation List]].&lt;br /&gt;
===Denial of service attack===&lt;br /&gt;
Any attack that affects the availability of a service. Reliability bugs that cause a service to crash or go into some sort of vegetative state are usually potential denial-of-service problems.&lt;br /&gt;
===DES===&lt;br /&gt;
The Data Encryption Standard. An encryption algorithm standardized by the US Government. The key length is too short, so this algorithm should be considered insecure. The effective key strength is 56 bits; the actual key size is 64 bits — 8 bits are wasted. However, there are variations such as Triple DES and DESX that increase security while also increasing the key size.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Advanced Encryption Standard|Advanced Encryption Standard]], [[#Triple DES|Triple DES]].&lt;br /&gt;
===DESX===&lt;br /&gt;
An extended version of DES that increases the resistance to brute-force attack in a highly efficient way by increasing the key length. The extra key material is mixed into the encryption process, using XORs. This technique does not improve resistance to differential attacks, but such attacks are still generally considered unfeasible against DES.&lt;br /&gt;
&lt;br /&gt;
See also: [[#DES|DES]].&lt;br /&gt;
===Dictionary attack===&lt;br /&gt;
An attack against a cryptographic system, using precomputating values to build a dictionary. For example, in a password system, one might keep a dictionary mapping ciphertext pairs in plaintext form to keys for a single plaintext that frequently occurs. A large enough key space can render this attack useless. In a password system, there are similar dictionary attacks, which are somewhat alleviated by salt. The end result is that the attacker — once he knows the salt — can do a “Crack”-style dictionary attack. Crack-style attacks can be avoided to some degree by making the password verifier computationally expensive to compute. Or select strong random passwords, or do not use a password-based system.&lt;br /&gt;
===Differential cryptanalysis===&lt;br /&gt;
A type of cryptographic attack where an attacker who can select related inputs learns information about the key from comparing the outputs. Modern ciphers of merit are designed in such a way as to thwart such attacks. Also note that such attacks generally require enough chosen plaintexts as to be considered unfeasible, even when there is a cipher that theoretically falls prey to such a problem.&lt;br /&gt;
===Diffie-Hellman key exchange===&lt;br /&gt;
A method for exchanging a secret key over an untrusted medium in such a way as to preserve the secrecy of the key. The two parties both contribute random data that factors into the final shared secret. The fundamental problem with this method is authenticating the party with whom you exchanged keys. The simple Diffie-Hellman protocol does not do that. One must also use some public-key authentication system such as DSA.&lt;br /&gt;
&lt;br /&gt;
See also: [[#DSA|DSA]], [[#Station-to-station protocol|Station-to-station protocol]].&lt;br /&gt;
===Digest size===&lt;br /&gt;
The output size for a hash function.&lt;br /&gt;
===Digital signature===&lt;br /&gt;
Data that proves that a document (or other piece of data) was not modified since being processed by a particular entity. Generally, what this really means is that — if someone ‘signs’ a piece of data — anyone who has the right public key can demonstrated which private key was used to sign the data.&lt;br /&gt;
===Digital Signature Algorithm===&lt;br /&gt;
See also: [[#DSA|DSA]].&lt;br /&gt;
===Distinguished Encoding Rules===&lt;br /&gt;
A set of rules used that describes how to encode ASN.1 data objects unambiguously.&lt;br /&gt;
&lt;br /&gt;
See also: [[#ASN.1|ASN.1]].&lt;br /&gt;
&lt;br /&gt;
===Distinguished Name===&lt;br /&gt;
In an X.509 certificate, a field that uniquely specifies the user or group to which the certificate is bound. Usually, the Distinguished Name will contain a user’s name or User ID, an organizational name, and a country designation. For a server certificate, it will often contain the DNS name of the machine.&lt;br /&gt;
===DN===&lt;br /&gt;
See also: [[#Distinguished Name|Distinguished Name]].&lt;br /&gt;
===DoS===&lt;br /&gt;
Denial of Service.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Denial of service attack|Denial of service attack]].&lt;br /&gt;
===DSA===&lt;br /&gt;
The Digital Signature Algorithm, a public key algorithm dedicated to digital signatures which was standardized by NIST. It is based on the same mathematical principles as Diffie-Hellman.&lt;br /&gt;
==E==&lt;br /&gt;
===Eavesdropping attack===&lt;br /&gt;
Any attack on a data connection where one simply records or views data instead of tampering with the connection.&lt;br /&gt;
===ECB Mode===&lt;br /&gt;
See also: [[#Electronic Code Book mode|Electronic Code Book mode]].&lt;br /&gt;
===ECC===&lt;br /&gt;
See also: [[#Eliptic Curve Cryptography|Eliptic Curve Cryptography]].&lt;br /&gt;
===EGD===&lt;br /&gt;
See also: [[#Entropy Gathering Daemon|Entropy Gathering Daemon]].&lt;br /&gt;
===Electronic Code Book mode===&lt;br /&gt;
An encryption mode for block ciphers that is more or less a direct use of the underlying block cipher. The only difference is that a message is padded out to a multiple of the block length. This mode should not be used under any circumstances.&lt;br /&gt;
===Eliptic Curve Cryptography===&lt;br /&gt;
A type of public key cryptography that — due to smaller key sizes — tends to be more efficient that standard cryptography. The basic algorithms are essentially the same, except that the operations are performed over different mathematical groups (called eliptic curves).&lt;br /&gt;
===EME-OAEP padding===&lt;br /&gt;
A padding scheme for public key cryptography that uses a “random” value generated, using a cryptographic hash function in order to prevent particular types of attacks against RSA.&lt;br /&gt;
&lt;br /&gt;
See also: [[#PKCS #1|PKCS #1 padding]].&lt;br /&gt;
===Encrypt-then-authenticate===&lt;br /&gt;
When using a cipher to encrypt and a MAC to provide message integrity, this paradigm specifies that one encrypts the plaintext, then MACs the ciphertext. This paradigm has theoretically appealing properties and is recommended to use in practice.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Authenticate-and-encrypt|Authenticate-and-encrypt]], [[#Authenticate-then-encrypt|Authenticate-then-encrypt]].&lt;br /&gt;
===Endianess===&lt;br /&gt;
The byte ordering scheme that a machine uses (usually either little endian or big endian).&lt;br /&gt;
&lt;br /&gt;
See also:[[#Big endian|Big endian]], [[#Little endian|Little endian]].&lt;br /&gt;
===Entropy===&lt;br /&gt;
Refers to the inherent unknowability of data to external observers. If a bit is just as likely to be a 1 as a 0 and a user does not know which it is, then the bit contains one bit of entropy.&lt;br /&gt;
===Entropy Gathering Daemon===&lt;br /&gt;
A substitute for /dev/random; a tool used for entropy harvesting.&lt;br /&gt;
===Entropy harvester===&lt;br /&gt;
A piece of software responsible for gathering entropy from a machine and distilling it into small pieces of high entropy data. Often an entropy harvester will produce a seed for a cryptographic pseudo-random number generator.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Entropy|Entropy]], [[#Pseudo-random number generator|Pseudo-random number generator]].&lt;br /&gt;
===Ephemeral keying===&lt;br /&gt;
Using one-time public key pairs for session key exchange in order to prevent recovering previous session keys if a private key is compromised. Long-term public key pairs are still used to establish identity.&lt;br /&gt;
===Euclidian algorithm===&lt;br /&gt;
An algorithm that computes the greatest common divisor of any two numbers.&lt;br /&gt;
===Extended Euclidian algorithm===&lt;br /&gt;
An algorithm used to compute the inverse of a number modulo “some other number.”&lt;br /&gt;
==F==&lt;br /&gt;
===Fingerprint===&lt;br /&gt;
The output of a cryptographic hash function.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Message digest|Message digest]].&lt;br /&gt;
===FIPS===&lt;br /&gt;
Federal Information Processing Standard; a set of standards from NIST.&lt;br /&gt;
===FIPS-140===&lt;br /&gt;
A standard authored by the U.S. National Institute of Standards and Technology, that details general security requirements for cryptographic software deployed in a government systems (primarily cryptographic providers).&lt;br /&gt;
&lt;br /&gt;
See also: [[#NIST|NIST]], [[#FIPS|FIPS]].&lt;br /&gt;
===Format string attack===&lt;br /&gt;
The C standard library uses specifiers to format output. If an attacker can control the input to such a format string, he can often write to arbitrary memory locations.&lt;br /&gt;
===Forward secrecy===&lt;br /&gt;
Ensuring that the compromise of a secret does not divulge information that could lead to data protected prior to the compromise. In many systems with forward secrecy, it is only provided on a per-session basis, meaning that a key compromise will not affect previous sessions, but would allow an attacker to decrypt previous messages sent as a part of the current session.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Perfect forward secrecy|Perfect forward secrecy]].&lt;br /&gt;
==G==&lt;br /&gt;
==H==&lt;br /&gt;
===Hash function===&lt;br /&gt;
A function that maps a string of arbitrary length to a fixed size value in a deterministic manner. Such a function may or may not have cryptographic applications.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Cryptographic hash function|Cryptographic hash function]], [[#Universal hash function|Universal hash function]], [[#One-way hash function|One-way hash function]].&lt;br /&gt;
===Hash function (cryptographic)===&lt;br /&gt;
See also: [[#Cryptographic hash function|Cryptographic hash function]].&lt;br /&gt;
===Hash function (one-way)===&lt;br /&gt;
See also: [[#One-way hash function|One-way hash function]].&lt;br /&gt;
===Hash function (universal)===&lt;br /&gt;
See also: [[#Universal hash function|Universal hash function]].&lt;br /&gt;
===Hash output===&lt;br /&gt;
See also: [[#Hash value|Hash value]].&lt;br /&gt;
===Hash value===&lt;br /&gt;
The output of a hash function.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Fingerprint|Fingerprint]], [[#Message digest|Message digest]].&lt;br /&gt;
===hash127===&lt;br /&gt;
A fast universal hash function from Dan Bernstein.&lt;br /&gt;
===HMAC===&lt;br /&gt;
A well-known algorithm for converting a cryptographic one-way hash function into a message authentication code.&lt;br /&gt;
==I==&lt;br /&gt;
===IDEA===&lt;br /&gt;
A block cipher with 128-bit keys and 64-bit blocks popularly used with PGP. It is currently protected by patents.&lt;br /&gt;
===Identity establishment===&lt;br /&gt;
Authentication.&lt;br /&gt;
===IEEE P1363===&lt;br /&gt;
An IEEE standard for eliptic curve cryptography. Implementing the standard requires licensing patents from Certicom.&lt;br /&gt;
===Indirect CRLs===&lt;br /&gt;
A CRL issued by a third party, that can contain certificates from multiple CA’s.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Certificate|Certificate]], [[#Certificate Revocation List|Certificate Revocation List]], [[#Certification Authority|Certification Authority]].&lt;br /&gt;
===Initialization vector===&lt;br /&gt;
A value used to initialize a cryptographic algorithm. Often, the implication is that the value must be random.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Nonce|Nonce]], [[#Salt|Salt]].&lt;br /&gt;
===Input validation===&lt;br /&gt;
The act of determining that data input to a program is sound.&lt;br /&gt;
===Integer overflow===&lt;br /&gt;
When an integer value is too big to be held by its associated data type, the results can often be disastrous. This is often a problem when converting unsigned numbers to signed values.&lt;br /&gt;
===Integrity checking===&lt;br /&gt;
The act of checking whether a message has been modified either maliciously or by accident. Cryptographically strong message integrity algorithms should always be used when integrity is important.&lt;br /&gt;
===Interleaved encryption===&lt;br /&gt;
Processing the encryption of a message as multiple messages, generally treating every nth block as part of a single message.&lt;br /&gt;
===ISO/IEC 17799===&lt;br /&gt;
Provides best practice recommendations on information security management for use by those who are responsible for initiating, implementing or maintaining information security management systems. &lt;br /&gt;
===IV===&lt;br /&gt;
See also: [[#Initialization vector|Initialization vector]].&lt;br /&gt;
&lt;br /&gt;
==J==&lt;br /&gt;
===Jail===&lt;br /&gt;
A restricted execution environment meant to compartmentalize a process, so that — even if it has security problems — it cannot hurt resources which it would not normally have access to use. On FreeBSD, a system call similar to chroot that provides compartmentalization. Unlike chroot, it can also restrict network resources in addition to file system resources.&lt;br /&gt;
&lt;br /&gt;
See also: [[#chroot|chroot]].&lt;br /&gt;
&lt;br /&gt;
==K==&lt;br /&gt;
===Kerberos===&lt;br /&gt;
An authentication protocol that relies solely on symmetric cryptography, as opposed to public key cryptography. It still relies on a trusted third party (an authentication server). While Kerberos is often looked upon as a way to avoid problems with Public Key Infrastructure, it can be difficult to scale Kerberos beyond medium-sized organizations.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Public Key Infrastructure|Public Key Infrastructure]], [[#Trusted third party|Trusted third party]].&lt;br /&gt;
===Key agreement===&lt;br /&gt;
The process of two parties agreeing on a shared secret, where both parties contribute material to the key.&lt;br /&gt;
===Key establishment===&lt;br /&gt;
The process of agreeing on a shared secret, where both parties contribute material to the key.&lt;br /&gt;
===Key exchange===&lt;br /&gt;
The process of two parties agreeing on a shared secret, usually implying that both parties contribute to the key.&lt;br /&gt;
===Key management===&lt;br /&gt;
Mechanisms and process for secure creation, storage, and handling of key material.&lt;br /&gt;
===Key schedule===&lt;br /&gt;
In a block cipher, keys used for individual “rounds” of encryption, derived from the base key in a cipher-dependent manner.&lt;br /&gt;
===Key transport===&lt;br /&gt;
When one party picks a session key and communicates it to a second party.&lt;br /&gt;
===Keystream Output===&lt;br /&gt;
from a stream cipher.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Pseudo-random number generator|Pseudo-random number generator]], [[#Stream cipher|Stream cipher]].&lt;br /&gt;
==L==&lt;br /&gt;
===LDAP===&lt;br /&gt;
Lightweight Directory Access Protocol. A directory protocol commonly used for storing and distributing CRLs.&lt;br /&gt;
===Length extension attack===&lt;br /&gt;
A class of attack on message authentication codes, where a tag can be forged without the key by extending a pre-existing message in a particular way. CBC-MAC in its simplest form has this problem, but variants protect against it (particularly OMAC).&lt;br /&gt;
&lt;br /&gt;
See also: [[#Message Authentication Code|Message Authentication Code]], [[#OMAC|OMAC]].&lt;br /&gt;
===LFSR===&lt;br /&gt;
See also: [[#Linear Feedback Shift Register|Linear Feedback Shift Register]].&lt;br /&gt;
&lt;br /&gt;
===Linear cryptanalysis===&lt;br /&gt;
A type of cryptanalytic attack where linear approximations of behavior are used. Modern ciphers of merit are designed in such a way as to thwart such attacks. Also note that such attacks generally require enough chosen plaintexts as to be considered unfeasible — even when there is a cipher that theoretically falls prey to such a problem (such as DES).&lt;br /&gt;
===Linear Feedback Shift Register===&lt;br /&gt;
A non-cryptographic class of pseudo-random number generators, where output is determined by shifting out &amp;amp;quot;output&amp;amp;quot; bits and shifting in &amp;amp;quot;input&amp;amp;quot; bits, where the input bits are a function of the internal state of the register, perhaps combined with new entropy. LFSRs are based on polynomial math, and are not secure in and of themselves; however, they can be put to good use as a component in more secure cryptosystems.&lt;br /&gt;
===Little endian===&lt;br /&gt;
Refers to machines representing words of data least significant byte first, such as the Intel x86.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Big endian|Big endian]].&lt;br /&gt;
==M==&lt;br /&gt;
===MAC===&lt;br /&gt;
See also: [[#Message Authentication Code|Message Authentication Code]].&lt;br /&gt;
&lt;br /&gt;
===Man-in-the- middle attack===&lt;br /&gt;
An eavesdropping attack where a client’s communication with a server is proxied by an attacker. Generally, the implication is that the client performs a cryptographic key exchange with an entity and fails to authenticate that entity, thus allowing an attacker to look like a valid server.&lt;br /&gt;
===Matyas-Meyer-Oseas===&lt;br /&gt;
A construction for turning a block cipher into a cryptographic one-way hash function.&lt;br /&gt;
===MCF===&lt;br /&gt;
The Modular Crypt Format, a de-facto data format standard for storing password hashes commonly used on UNIX boxes as a replacement for the traditional UNIX crypt() format.&lt;br /&gt;
===MD-strengthening===&lt;br /&gt;
Merkel-Damgard strengthening, a general method for turning a collision- resistant compression function into a collision-resistant hash function by adding padding and an encoded length to the end of the input message. The key point behind MD-strengthening is that no possible input to the underlying hash function can be the tail end of a different input.&lt;br /&gt;
===MD2===&lt;br /&gt;
A cryptographic hash function optimized for 16-bit platforms. It has poor performance characteristics on other platforms and has a weak internal structure.&lt;br /&gt;
===MD4===&lt;br /&gt;
A cryptographic hash function that is known to be broken and should not be used under any circumstances.&lt;br /&gt;
===MD5===&lt;br /&gt;
A popular and fast cryptographic hash function that outputs 128-bit message digests. Its internal structure is known to be weak and should be avoided if at all possible.&lt;br /&gt;
===MD5-MCF===&lt;br /&gt;
A way of using MD5 to store password authentication information, using the modular crypt format.&lt;br /&gt;
&lt;br /&gt;
See also: [[#MCF|MCF]], [[#MD5|MD5]].&lt;br /&gt;
===MDC2===&lt;br /&gt;
A construction for turning a block cipher into a cryptographic hash function, where the output length is twice the block size of the cipher.&lt;br /&gt;
===Meet-in-the- middle attack===&lt;br /&gt;
A theoretical attack against encrypting a message twice using a single block cipher and two different keys. For example, double encryption with DES theoretically is no more secure than DES, which is why Triple DES became popular (it gives twice the effective key strength).&lt;br /&gt;
===Message Authentication Code===&lt;br /&gt;
A function that takes a message and a secret key (and possibly a nonce) and produces an output that cannot, in practice, be forged without possessing the secret key.&lt;br /&gt;
===Message digest===&lt;br /&gt;
The output of a hash function.&lt;br /&gt;
===Message integrity===&lt;br /&gt;
A message has integrity if it maintains the value it is supposed to maintain, as opposed to being modified on accident or as part of an attack.&lt;br /&gt;
===Methodology===&lt;br /&gt;
A mature set of processes applied to various stages of an applications' lifecycle to help reduce the likelihood of security vulnerabilities presence or exploitation.&lt;br /&gt;
&lt;br /&gt;
===Miller-Rabin===&lt;br /&gt;
A primality test that is efficient because it is probabilistic, meaning that there is some chance it reports a composite (non-prime) number as a prime. There is a trade-off between efficiency and probability, but one can gain extremely high assurance without making unreasonable sacrifices in efficiency.&lt;br /&gt;
===Modulus===&lt;br /&gt;
In the context of public key cryptography, a value by which all other values are reduced. That is, if a number is bigger than the modulus, the value of the number is considered to be the same as if the number were the remainder after dividing the number by the modulus.&lt;br /&gt;
==N==&lt;br /&gt;
===Near-collision resistance===&lt;br /&gt;
Given a plaintext value and the corresponding hash value, it should be computationally unfeasible to find a second plaintext value that gives the same hash value.&lt;br /&gt;
===NIST===&lt;br /&gt;
The National Institute of Standards and Technology is a division of the U.S. Department of Commerce. NIST issues standards and guidelines, with the hope that they will be adopted by the computing community.&lt;br /&gt;
===Non-repudiation===&lt;br /&gt;
The capability of establishing that a message was signed by a particular entity. That is, a message is said to be non-repudiatable when a user sends it, and one can prove that the user sent it. In practice, cryptography can demonstrate that only particular key material was used to produce a message. There are always legal defenses such as stolen credentials or duress.&lt;br /&gt;
===Nonce===&lt;br /&gt;
A value used with a cryptographic algorithm that must be unique in order to maintain the security of the system. Generally, the uniqueness requirement holds only for a single key — meaning that a {key, nonce} pair should never be reused.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Initialization vector|Initialization vector]], [[#Salt|Salt]].&lt;br /&gt;
&lt;br /&gt;
==O==&lt;br /&gt;
===OCB mode===&lt;br /&gt;
See also: [[#Offset Code Book mode|Offset Code Book mode]].&lt;br /&gt;
===OCSP===&lt;br /&gt;
See also: Online Certificate Status Protocol.&lt;br /&gt;
===OCSP responder===&lt;br /&gt;
The server side software that answers OCSP requests.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Online Certificate Status Protocol|Online Certificate Status Protocol]].&lt;br /&gt;
===OFB mode===&lt;br /&gt;
See also: [[#Output Feedback mode|Output Feedback mode]].&lt;br /&gt;
===Offset Code Book mode===&lt;br /&gt;
A patented encryption mode for block ciphers that provides both secrecy and message integrity and is capable of doing so at high speeds.&lt;br /&gt;
===OMAC===&lt;br /&gt;
One-key CBC-MAC. A secure, efficient way for turning a block cipher into a message authentication code. It is an improvement of the CBC-MAC, which is not secure in the arbitrary case. Other CBC-MAC variants use multiple keys in order to fix the problem with CBC-MAC. OMAC uses a single key and still has appealing provable security properties.&lt;br /&gt;
===One-time pad===&lt;br /&gt;
A particular cryptographic system that is provably secure in some sense, but highly impractical, because it requires a bit of entropy for every bit of message.&lt;br /&gt;
===One-time password===&lt;br /&gt;
A password that is only valid once. Generally, such passwords are derived from some master secret — which is shared by an entity and an authentication server — and are calculated via a challenge-response protocol.&lt;br /&gt;
===One-way hash function===&lt;br /&gt;
A hash function, where it is computationally unfeasible to determine anything about the input from the output.&lt;br /&gt;
===Online Certificate Status Protocol===&lt;br /&gt;
A protocol for determining whether a digital certificate is valid in real time without using CRLs. This protocol (usually abbreviated OCSP) is specified in RFC 2560.&lt;br /&gt;
===Output Feedback mode===&lt;br /&gt;
A block cipher mode that turns a block cipher into a stream cipher. The mode works by continually encrypting the previous block of keystream. The first block of keystream is generated by encrypting an initialization vector.&lt;br /&gt;
==P==&lt;br /&gt;
===Padding===&lt;br /&gt;
Data added to a message that is not part of the message. For example, some block cipher modes require messages to be padded to a length that is evenly divisible by the block length of the cipher — i.e., the number of bytes that the cipher processes at once.&lt;br /&gt;
===PAM===&lt;br /&gt;
Pluggable Authentication Modules is a technology for abstracting out authentication at the host level. It is similar to SASL, but is a bit higher up in the network stack and tends to be a much easier technology to use, particularly for system administrators, who can configure authentication policies quite easily using PAM.&lt;br /&gt;
&lt;br /&gt;
See also: [[#SASL|SASL]].&lt;br /&gt;
===Partial collision resistance===&lt;br /&gt;
When it is unfeasible to find two arbitrary inputs to a hash function that produce similar outputs — i.e., outputs that differ in only a few bits.&lt;br /&gt;
===Passive attack===&lt;br /&gt;
See also: [[#Eavesdropping attack|Eavesdropping attack]].&lt;br /&gt;
&lt;br /&gt;
===Passphrase===&lt;br /&gt;
A synonym for “password,” meant to encourage people to use longer (it is hoped, more secure) values.&lt;br /&gt;
===Password===&lt;br /&gt;
A value that is used for authentication.&lt;br /&gt;
===PBKDF2===&lt;br /&gt;
Password-Based Key Derivation Function #2. An algorithm defined in PKCS #5 for deriving a random value from a password.&lt;br /&gt;
===PEM encoding===&lt;br /&gt;
A simple encoding scheme for cryptographic objects that outputs printable values (by Base 64 encoding a DER-encoded representation of the cryptographic object). The scheme was first introduced in Privacy Enhanced Mail, a defunct way of providing E-mail security.&lt;br /&gt;
===Perfect forward secrecy===&lt;br /&gt;
Ensuring that the compromise of a secret does not divulge information that could lead to the recovery of data protected prior to the compromise.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Forward secrecy|Forward secrecy]].&lt;br /&gt;
===PKCS #1===&lt;br /&gt;
Public Key Cryptography Standard #1. A standard from RSA Labs specifying how to use the RSA algorithm for encrypting and signing data.&lt;br /&gt;
===PKCS #1===&lt;br /&gt;
padding  This form of padding can encrypt messages up to 11 bytes smaller than the modulus size in bytes. You should not use this method for any purpose other than encrypting session keys or hash values.&lt;br /&gt;
===PKCS #10===&lt;br /&gt;
Describes a standard syntax for certification requests.&lt;br /&gt;
===PKCS #11===&lt;br /&gt;
Specifies a programming interface called Cryptoki for portable cryptographic devices of all kinds.&lt;br /&gt;
===PKCS #3===&lt;br /&gt;
Public Key Cryptography Standard #3. A standard from RSA Labs specifying how to implement the Diffie-Hellman key exchange protocol.&lt;br /&gt;
===PKCS #5===&lt;br /&gt;
Public Key Cryptography Standard #5. A standard from RSA Labs specifying how to derive cryptographic keys from a password.&lt;br /&gt;
===PKCS #7===&lt;br /&gt;
Public Key Cryptography Standard #7. A standard from RSA Labs specifying a generic syntax for data that may be encrypted or signed.&lt;br /&gt;
===PKI===&lt;br /&gt;
See also: [[#Public Key Infrastructure|Public Key Infrastructure]].&lt;br /&gt;
===Plaintext===&lt;br /&gt;
An unencrypted message.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Ciphertext|Ciphertext]].&lt;br /&gt;
===PMAC===&lt;br /&gt;
The MAC portion of the OCB block cipher mode. It is a patented way of turning a block cipher into a secure, parallelizable MAC.&lt;br /&gt;
===Precomputation attack===&lt;br /&gt;
Any attack that involves precomputing significant amounts of data in advance of opportunities to launch an attack. A dictionary attack is a common precomputation attack.&lt;br /&gt;
===Private key===&lt;br /&gt;
In a public key cryptosystem, key material that is bound tightly to an individual entity that must remain secret in order for there to be secure communication.&lt;br /&gt;
===Privilege separation===&lt;br /&gt;
A technique for trying to minimize the impact that a programming flaw can have, where operations requiring privilege are separated out into a small, independent component (hopefully audited with care). Generally, the component is implemented as an independent process, and it spawns off a non-privileged process to do most of the real work. The two processes keep open a communication link, speaking a simple protocol.&lt;br /&gt;
===PRNG===&lt;br /&gt;
See also: [[#Pseudo-random number generator|Pseudo-random number generator]].&lt;br /&gt;
===Pseudo-random number generator===&lt;br /&gt;
An algorithm that takes data and stretches it into a series of random-looking outputs. Cryptographic pseudo-random number generators may be secure if the initial data contains enough entropy. Many popular pseudo-random number generators are not secure.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Stream cipher|Stream cipher]].&lt;br /&gt;
&lt;br /&gt;
===Public key===&lt;br /&gt;
In a public key cryptosystem, the key material that can be published publicly without compromising the security of the system. Generally, this material must be published; its authenticity must be determined definitively.&lt;br /&gt;
===Public Key Infrastructure===&lt;br /&gt;
A system that provides a means for establishing trust as to what identity is associated with a public key. Some sort of Public Key Infrastructure (PKI) is necessary to give reasonable assurance that one is communicating securely with the proper party, even if that infrastructure is ad hoc”&lt;br /&gt;
==Q==&lt;br /&gt;
==R==&lt;br /&gt;
===RA===&lt;br /&gt;
See also: [[#Registration Authority|Registration Authority]].&lt;br /&gt;
===Race condition===&lt;br /&gt;
A class of error in environments that are multi-threaded or otherwise multi- tasking, where an operation is falsely assumed to be atomic. That is, if two operations overlap instead of being done sequentially, there is some risk of the resulting computation not being correct. There are many cases where such a condition can be security critical.&lt;br /&gt;
&lt;br /&gt;
See also: [[#TOCTOU problem|TOCTOU problem]].&lt;br /&gt;
===Randomness===&lt;br /&gt;
A measure of how unguessable data is.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Entropy|Entropy]].&lt;br /&gt;
===RC2===&lt;br /&gt;
A block cipher with variable key sizes and 64-bit blocks.&lt;br /&gt;
===RC4===&lt;br /&gt;
A widely used stream cipher that is relatively fast but with some significant problems. One practical problem is that it has a weak key setup algorithm, though this problem can be mitigated with care. Another more theoretical problem is that RC4’s output is easy to distinguish from a truly random stream of numbers. This problem indicates that RC4 is probably not a good long-term choice for data security.&lt;br /&gt;
===RC5===&lt;br /&gt;
A block cipher that has several tunable parameters.&lt;br /&gt;
===Registration Authority===&lt;br /&gt;
An organization that is responsible for validating the identity of entities trying to obtain credentials in a Public Key Infrastructure.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Certification Authority|Certification Authority]], [[#Public Key Infrastructure|Public Key Infrastructure]].&lt;br /&gt;
===Rekeying===&lt;br /&gt;
Changing a key in a cryptographic system.&lt;br /&gt;
===Related key attack===&lt;br /&gt;
A class of cryptographic attack where one takes advantage of known relationships between keys to expose information about the keys or the messages those keys are protecting.&lt;br /&gt;
===Revocation===&lt;br /&gt;
In the context of Public Key Infrastructure, the act of voiding a digital certificate.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Public Key Infrastructure|Public Key Infrastructure]], [[#X.509 certificate|X.509 certificate]].&lt;br /&gt;
===RIPEMD-160===&lt;br /&gt;
A cryptographic hash function that is well regarded. It has a 160-bit output, and is a bit slower than SHA1.&lt;br /&gt;
===RMAC===&lt;br /&gt;
A construction for making a Message Authentication Code out of a block cipher. It is not generally secure in the way that OMAC is, and is generally considered not worth using due to the existence of better alternatives.&lt;br /&gt;
&lt;br /&gt;
See also: [[#OMAC|OMAC]].&lt;br /&gt;
===Rollback attack===&lt;br /&gt;
An attack where one forces communicating parties to agree on an insecure protocol version.&lt;br /&gt;
===Root certificate===&lt;br /&gt;
A certificate that is intrinsically trusted by entities in a Public Key Infrastructure — generally should be transported over a secure medium. Root certificates belong to a Certification Authority and are used to sign other certificates that are deemed to be valid. When a system tries to establish the validity of a certificate, one of the first things that should happen is that it should look for a chain of trust to a known, trusted root certificate. That is, if the certificate to be validated is not signed by a root, one checks the certificate(s) used to sign it to determine if those were signed by a root cert. Lather, rinse, repeat.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Public Key Infrastructure|Public Key Infrastructure]].&lt;br /&gt;
===Round===&lt;br /&gt;
In a block cipher, a group of operations applied as a unit that has an inverse that undoes the operation. Most block ciphers define a round operation and then apply that round operation numerous times — though often applying a different key for each round, where the round key is somehow derived from the base key.&lt;br /&gt;
===RSA===&lt;br /&gt;
A popular public key algorithm for encryption and digital signatures invented by Ron Rivest, Adi Shamir and Leonard Adleman. It is believed that, if factoring large numbers is computationally unfeasible, then RSA can be used securely in practice.&lt;br /&gt;
===RSASSA-PSS===&lt;br /&gt;
A padding standard defined in PKCS #1, used for padding data prior to RSA signing operations.&lt;br /&gt;
==S==&lt;br /&gt;
===S/Key===&lt;br /&gt;
A popular one-time password system.&lt;br /&gt;
&lt;br /&gt;
See also: [[#One-time password|One-time password]].&lt;br /&gt;
===S/MIME===&lt;br /&gt;
A protocol for secure electronic mail standardized by the IETF. It relies on standard X.509-based Public Key Infrastructure.&lt;br /&gt;
===SACL===&lt;br /&gt;
System Access Control List. In Windows, the part of an ACL that determines audit logging policy.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Access Control List|Access Control List]], [[#DACL|DACL]].&lt;br /&gt;
===Salt===&lt;br /&gt;
Data that can be public but is used to prevent against precomputation attacks.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Initialization vector|Initialization vector]], [[#Nonce|Nonce]].&lt;br /&gt;
===SASL===&lt;br /&gt;
The Simple Authentication and Security Layer, which is a method for adding authentication services to network protocols somewhat generically. It is also capable of providing key exchange in many circumstances.&lt;br /&gt;
===Secret key===&lt;br /&gt;
See also: [[#Symmetric key|Symmetric key]].&lt;br /&gt;
===Secure Socket Layer===&lt;br /&gt;
A popular protocol for establishing secure channels over a reliable transport, utilizing a standard X.509 Public Key Infrastructure for authenticating machines. This protocol has evolved into the TLS protocol, but the term SSL is often used to generically refer to both.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Transport Layer Security|Transport Layer Security]].&lt;br /&gt;
===Seed===&lt;br /&gt;
A value used to initialize a pseudo-random number generator.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Entropy|Entropy]], [[#Initialization vector|Initialization vector]], [[#Pseudo-random number generator|Pseudo-random number generator]].&lt;br /&gt;
&lt;br /&gt;
===Self-signed certificate===&lt;br /&gt;
A certificate signed by the private key associated with that certificate. In an X.509 Public Key Infrastructure, all certificates need to be signed. Since root certificates have no third-party signature to establish their authenticity, they are used to sign themselves. In such a case, trust in the certificate must be established by some other means.&lt;br /&gt;
===Serpent===&lt;br /&gt;
A modern block cipher with 128-bit blocks and variable-sized keys. A finalist in the AES competition, Serpent has a higher security margin by design than other candidates, and is a bit slower on typical 32-bit hardware as a result.&lt;br /&gt;
&lt;br /&gt;
See also: [[#AES|AES]].&lt;br /&gt;
===Session key===&lt;br /&gt;
A randomly generated key used to secure a single connection and then discarded.&lt;br /&gt;
===SHA-256===&lt;br /&gt;
A cryptographic hash function from NIST with 256-bit message digests.&lt;br /&gt;
===SHA-384===&lt;br /&gt;
SHA-512 with a truncated digest (as specified by NIST).&lt;br /&gt;
===SHA-512===&lt;br /&gt;
A cryptographic hash function from NIST with 512-bit message digests.&lt;br /&gt;
===SHA1===&lt;br /&gt;
A fairly fast, well regarded hash function with 160-bit digests that has been standardized by the National Institute of Standards and Technology (NIST).&lt;br /&gt;
===Shared secret===&lt;br /&gt;
A value shared by parties that may wish to communicate, where the secrecy of that value is an important component of secure communications. Typically, a shared secret is either an encryption key, a MAC key, or some value used to derive such keys.&lt;br /&gt;
===Shatter attack===&lt;br /&gt;
A class of attack on the Windows event system. The Windows messaging system is fundamentally fragile from a security perspective because it allows for arbitrary processes to insert control events into the message queue without sufficient mechanisms for authentication. Sometimes messages can be used to trick other applications to execute malicious code.&lt;br /&gt;
===Single sign-on===&lt;br /&gt;
Single sign-on allows you to access all computing resources that you should be able to reach by using a single set of authentication credentials that are presented a single time per login session. Single sign-on is a notion for improved usability of security systems that can often increase the security exposure of a system significantly.&lt;br /&gt;
===Snooping attacks===&lt;br /&gt;
Attacks where data is read off a network while in transit without modifying or destroying the data.&lt;br /&gt;
===SNOW===&lt;br /&gt;
A very fast stream cipher that is patent-free and seems to have a very high security margin.&lt;br /&gt;
===SQL Injection===&lt;br /&gt;
When an attacker can cause malicious SQL code to run by maliciously modifying data used to compose an SQL command.&lt;br /&gt;
===SSL===&lt;br /&gt;
See also: [[#Secure Socket Layer|Secure Socket Layer]].&lt;br /&gt;
===Stack smashing===&lt;br /&gt;
Overwriting a return address on the program execution stack by exploiting a buffer overflow. Generally, the implication is that the return address gets replaced with a pointer to malicious code.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Buffer overflow|Buffer overflow]].&lt;br /&gt;
===Station-to-station protocol===&lt;br /&gt;
A simple variant of the Diffie-Hellman key exchange protocol that provides key agreement and authenticates each party to the other. This is done by adding digital signatures (which must be done carefully).&lt;br /&gt;
&lt;br /&gt;
See also: [[#Diffie-Hellman key exchange|Diffie-Hellman key exchange]].&lt;br /&gt;
===Stream cipher===&lt;br /&gt;
A pseudo-random number generator that is believed to be cryptographically strong and always produces the same stream of output given the same initial seed (i.e., key). Encrypting with a stream cipher consists of combining the plaintext with the keystream, usually via XOR.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Pseudo-random number generator|Pseudo-random number generator]].&lt;br /&gt;
===Strong collision resistance===&lt;br /&gt;
Strong collision resistance is a property that a hash function may have (and a good cryptographic hash function will have), characterized by it being computationally unfeasible to find two arbitrary inputs that yield the same output.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Hash function|Hash function]], [[#Weak collision resistance|Weak collision resistance]].&lt;br /&gt;
===Surreptitious forwarding===&lt;br /&gt;
An attack on some public key cryptosystems where a malicious user decrypts a digitally signed message and then encrypts the message using someone else’s public key: giving the end receiver the impression that the message was originally destined for them.&lt;br /&gt;
===Symmetric cryptography===&lt;br /&gt;
Cryptography that makes use of shared secrets as opposed to public keys.&lt;br /&gt;
===Symmetric key===&lt;br /&gt;
See also: [[#Shared secret|Shared secret]].&lt;br /&gt;
==T==&lt;br /&gt;
===Tag===&lt;br /&gt;
The result of applying a keyed message authentication code to a message.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Message Authentication Code|Message Authentication Code]].&lt;br /&gt;
===Tamper-proofing===&lt;br /&gt;
See also: [[#Anti-tampering|Anti-tampering]].&lt;br /&gt;
===Threat model===&lt;br /&gt;
A representation of the system threats that are expected to be reasonable. This includes denoting what kind of resources an attacker is expected to have, in addition to what kinds of things the attacker may be willing to try to do. Sometimes called an architectural security assessment.&lt;br /&gt;
===Time of check, time of use problem===&lt;br /&gt;
See also: [[#TOCTOU problem|TOCTOU problem]].&lt;br /&gt;
===TLS===&lt;br /&gt;
See also: [[#Transport Layer Security|Transport Layer Security]].&lt;br /&gt;
===TMAC===&lt;br /&gt;
A two-keyed variant of the CBC-MAC that overcomes the fundamental limitation of that MAC.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Message Authentication Code|Message Authentication Code]], [[#CBC-MAC|CBC-MAC]], [[#OMAC|OMAC]].&lt;br /&gt;
===TOCTOU problem===&lt;br /&gt;
Time-of-check, time-of-use race condition. A type of race condition between multiple processes on a file system. Generally what happens is that a single program checks some sort of property on a file, and then in subsequent instructions tries to use the resource if the check succeeded. The problem is that — even if the use comes immediately after the check — there is often some significant chance that a second process can invalidate the check in a malicious way. For example, a privileged program might check write privileges on a valid file, and the attacker can then replace that file with a symbolic link to the system password file.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Race condition|Race condition]].&lt;br /&gt;
===Transport Layer Security===&lt;br /&gt;
The successor to SSL, a protocol for establishing secure channels over a reliable transport, using a standard X.509 Public Key Infrastructure for authenticating machines. The protocol is standardized by the IETF.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Secure Socket Layer|Secure Socket Layer]].&lt;br /&gt;
===Triple DES===&lt;br /&gt;
A variant of the original Data Encryption Standard that doubles the effective security. Often abbreviated to 3DES. The security level of 3DES is still considered to be very high, but there are faster block ciphers that provide comparable levels of security — such as AES.&lt;br /&gt;
===Trojan===&lt;br /&gt;
See also: [[#Backdoor|Backdoor]].&lt;br /&gt;
===Trojan Horse===&lt;br /&gt;
See also: [[#Backdoor|Backdoor]].&lt;br /&gt;
===Trusted third party===&lt;br /&gt;
An entity in a system to whom entities must extend some implicit trust. For example, in a typical Public Key Infrastructure, the Certification Authority constitutes a trusted third party.&lt;br /&gt;
===Twofish===&lt;br /&gt;
A modern block cipher with 128-bit blocks and variable-sized keys.   A finalist in the AES competition; it is an evolution of the Blowfish cipher.&lt;br /&gt;
&lt;br /&gt;
See also: [[#AES|AES]], [[#Blowfish|Blowfish]].&lt;br /&gt;
==U==&lt;br /&gt;
===UMAC===&lt;br /&gt;
A secure MAC based on a set of universal hash functions that is extremely fast in software but so complex that there has never been a validated implementation.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Universal hash function|Universal hash function]].&lt;br /&gt;
===Universal hash function===&lt;br /&gt;
A keyed hash function that has ideal hash properties. In practice, the only practical functions of this nature are really &amp;amp;quot;almost universal&amp;amp;quot; hash functions, meaning they come very close to being ideal. Universal and near-universal hash functions are not cryptographically secure when used naively for message authentication but can be adapted to be secure for this purpose easily.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Cryptographic hash function|Cryptographic hash function]], [[#Hash function|Hash function]], [[#One-way hash function|One-way hash function]].&lt;br /&gt;
&lt;br /&gt;
==V==&lt;br /&gt;
===Validation===&lt;br /&gt;
The act of determining that data is sound. In security, generally used in the context of validating input.&lt;br /&gt;
==W==&lt;br /&gt;
===Weak collision resistance===&lt;br /&gt;
A property that a hash function may have (and a good cryptographic hash function will have), characterized by it being unfeasible to find a second input that produces the same output as a known input.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Hash function|Hash function]], [[#Strong collision resistance|Strong collision resistance]].&lt;br /&gt;
===Whitelist===&lt;br /&gt;
When performing input validation, the set of items that, if matched, results in the input being accepted as valid. If there is no match to the whitelist, then the input is considered invalid. That is, a whitelist uses a &amp;amp;quot;default deny&amp;amp;quot; policy.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Blacklist|Blacklist]], [[#Default deny|Default deny]].&lt;br /&gt;
&lt;br /&gt;
===Window of vulnerability===&lt;br /&gt;
The period of time in which a vulnerability can possibly be exploited.&lt;br /&gt;
&lt;br /&gt;
===[[What are web applications?]]===&lt;br /&gt;
&lt;br /&gt;
==X==&lt;br /&gt;
===X.509 certificate===&lt;br /&gt;
A digital certificate that complies with the X.509 standard (produced by ANSI).&lt;br /&gt;
===XCBC-MAC===&lt;br /&gt;
A three-key variant of the CBC-MAC that overcomes the fundamental limitation of that MAC.&lt;br /&gt;
&lt;br /&gt;
See also: [[#Message Authentication Code|Message Authentication Code]], [[#CBC-MAC|CBC-MAC]], [[#OMAC|OMAC]].&lt;br /&gt;
&lt;br /&gt;
===XMACC===&lt;br /&gt;
A patented parallelizable Message Authentication Code.&lt;br /&gt;
===XSS===&lt;br /&gt;
See also: [[#Cross-site scripting|Cross-site scripting]].&lt;br /&gt;
==Y==&lt;br /&gt;
==Z==&lt;br /&gt;
&lt;br /&gt;
{{compactTOC}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Glossary]]&lt;/div&gt;</summary>
		<author><name>Cturra</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=User:Cturra&amp;diff=7249</id>
		<title>User:Cturra</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=User:Cturra&amp;diff=7249"/>
				<updated>2006-07-13T15:12:09Z</updated>
		
		<summary type="html">&lt;p&gt;Cturra: Initial draft&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==About Me==&lt;br /&gt;
General day-to-day app sec work for a large financial firm. &lt;br /&gt;
&lt;br /&gt;
==Contact==&lt;br /&gt;
web: http://www.bellotech.com&lt;br /&gt;
more contact info? I trust you can find it yourself :P&lt;/div&gt;</summary>
		<author><name>Cturra</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=How_to_Write_an_Application_Code_Review_Finding&amp;diff=7248</id>
		<title>How to Write an Application Code Review Finding</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=How_to_Write_an_Application_Code_Review_Finding&amp;diff=7248"/>
				<updated>2006-07-13T15:05:27Z</updated>
		
		<summary type="html">&lt;p&gt;Cturra: Updated risk discussion&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''How to write an application security finding'''&lt;br /&gt;
&lt;br /&gt;
{{Template:Stub}}&lt;br /&gt;
&lt;br /&gt;
==Choose a great name==&lt;br /&gt;
* ...&lt;br /&gt;
&lt;br /&gt;
==Identify the vulnerability==&lt;br /&gt;
* details of flaw, attack&lt;br /&gt;
* location in code and as URL&lt;br /&gt;
&lt;br /&gt;
==Discuss the risk==&lt;br /&gt;
There is value in both assigning a qualitative value to each finding and further discussing why this value was assigned. Some possible risk ratings are:&lt;br /&gt;
* Critical&lt;br /&gt;
* High&lt;br /&gt;
* Moderate&lt;br /&gt;
* Low&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Justifying the assigned risk ratings is very important. This will allow stakeholders (especially non-technical ones) to gain more of an understanding of the issue at hand. Two key points to identify are:&lt;br /&gt;
* Probability (ease of discovery and execution)&lt;br /&gt;
* Business/Technical impact&lt;br /&gt;
&lt;br /&gt;
==Suggest remediations==&lt;br /&gt;
* alternatives&lt;br /&gt;
* include effort required&lt;br /&gt;
* discuss residual risk&lt;br /&gt;
&lt;br /&gt;
==Include references==&lt;br /&gt;
* Important note: if you use OWASP materials for any reason, you must follow the terms of our license&lt;br /&gt;
&lt;br /&gt;
==Use a positive tone==&lt;br /&gt;
&lt;br /&gt;
by [[User:Vanderaj|Andrew van der Stock]] - (TBD: Depersonalize)&lt;br /&gt;
&lt;br /&gt;
Personally, I find all of these lists (the SANS Top 20, the old Top  10, the old Guide, etc) very negative - which is the way they were  designed. Even the chapter headings in the new book from Howard and LeBlanc are negative.&lt;br /&gt;
&lt;br /&gt;
A few years ago, that's how I thought, too. However, I've moved on. Sure we need to tell people, don't do X when it is necessary, but I think human nature works better when ideas are framed in a positive way. Certainly with business types who don't (yet) understand risk properly. Read this:&lt;br /&gt;
&lt;br /&gt;
http://www.asktog.com/columns/047HowToWriteAReport.html&lt;br /&gt;
&lt;br /&gt;
I write many reports which occasionally detail pretty bad news for  the recipients. Typically, they are not technical people (nor necessarily should they be - well-written reports should be understandable by lay people). Tog's essay was an eye opener for me and I wish I'd read it sooner. With my more positive approach, I'm  getting greater traction and things are getting fixed. Before, they'd often go &amp;quot;it's all too hard, we accept this risk, next!&amp;quot;&lt;br /&gt;
&lt;br /&gt;
I strongly believe we are here to enable secure business, not get in the way. Too many security folks* forget that we exist to make sure that ordinary folks don't lose money, don't see their details lost to identity thieves, and don't lose privacy. &amp;quot;Thou Shalt Not ...&amp;quot; lists don't really work in this &amp;quot;enable secure business&amp;quot; ideology.&lt;br /&gt;
&lt;br /&gt;
That's why the Guide has moved from negative titles to positive or neutral titles. I've tried as hard as I can do phrase the issue in terms of &amp;quot;This is the business reason why we check for this issue.  &lt;br /&gt;
&lt;br /&gt;
Check X. Do Y&amp;quot;, rather than say &amp;quot;Faulty authorization. Don't do X. It's bad. M'kay?&amp;quot;.&lt;br /&gt;
 &lt;br /&gt;
Only a few times I resorted to &amp;quot;don't do X&amp;quot; when it was truly unavoidable and that's a few times too many. Hopefully, by Guide 2.1 I can make it even more positive.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Category:How To]]&lt;br /&gt;
[[Category:OWASP Testing Project]]&lt;br /&gt;
[[Category:OWASP Code Review Project]]&lt;/div&gt;</summary>
		<author><name>Cturra</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Buffer_Overflow&amp;diff=6605</id>
		<title>Buffer Overflow</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Buffer_Overflow&amp;diff=6605"/>
				<updated>2006-06-23T18:46:00Z</updated>
		
		<summary type="html">&lt;p&gt;Cturra: fixed incorrect URL to phrack article&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Description==&lt;br /&gt;
&lt;br /&gt;
Attackers use buffer overflows to corrupt the execution stack of a web application. By sending carefully crafted input to a web application, an attacker can cause the web application to execute arbitrary code – effectively taking over the machine. Buffer overflows are not easy to discover and even when one is discovered, it is generally extremely difficult to exploit. Nevertheless, attackers have managed to identify buffer overflows in a staggering array of products and components. Another very similar class of flaws is known as format string attacks.&lt;br /&gt;
&lt;br /&gt;
Buffer overflow flaws can be present in both the web server or application server products that serve the static and dynamic aspects of the site, or the web application itself. Buffer overflows found in widely used server products are likely to become widely known and can pose a significant risk to users of these products. When web applications use libraries, such as a graphics library to generate images, they open themselves to potential buffer overflow attacks.&lt;br /&gt;
&lt;br /&gt;
Buffer overflows can also be found in custom web application code, and may even be more likely given the lack of scrutiny that web applications typically go through. Buffer overflow flaws in custom web applications are less likely to be detected because there will normally be far fewer hackers trying to find and exploit such flaws in a specific application. If discovered in a custom application, the ability to exploit the flaw (other than to crash the application) is significantly reduced by the fact that the source code and detailed error messages for the application are normally not available to the hacker. &lt;br /&gt;
&lt;br /&gt;
==Environments Affected==&lt;br /&gt;
&lt;br /&gt;
Almost all known web servers, application servers, and web application environments are susceptible to buffer overflows, the notable exception being environments written in interpreted languages like Java or Python, which are immune to these attacks (except for overflows in the Interpretor itself).&lt;br /&gt;
&lt;br /&gt;
==Examples and References==&lt;br /&gt;
&lt;br /&gt;
* [[:Category:OWASP Guide Project|OWASP Guide Project]] to Building Secure Web Applications and Web Services, Chapter 8: Data Validation &lt;br /&gt;
* Aleph One, “Smashing the Stack for Fun and Profit”, http://www.phrack.org/show.php?p=49&amp;amp;a=14 &lt;br /&gt;
* Mark Donaldson, “Inside the Buffer Overflow Attack: Mechanism, Method, &amp;amp; Prevention”, http://rr.sans.org/code/inside_buffer.php&lt;br /&gt;
&lt;br /&gt;
==How to Determine If You Are Vulnerable==&lt;br /&gt;
&lt;br /&gt;
For server products and libraries, keep up with the latest bug reports for the products you are using. For custom application software, all code that accepts input from users via the HTTP request must be reviewed to ensure that it can properly handle arbitrarily large input.&lt;br /&gt;
&lt;br /&gt;
==How to Protect Yourself==&lt;br /&gt;
&lt;br /&gt;
Keep up with the latest bug reports for your web and application server products and other products in your Internet infrastructure. Apply the latest patches to these products. Periodically scan your web site with one or more of the commonly available scanners that look for buffer overflow flaws in your server products and your custom web applications.&lt;br /&gt;
For your custom application code, you need to review all code that accepts input from users via the HTTP request and ensure that it provides appropriate size checking on all such inputs. This should be done even for environments that are not susceptible to such attacks as overly large inputs that are uncaught may still cause denial of service or other operational problems.&lt;/div&gt;</summary>
		<author><name>Cturra</name></author>	</entry>

	</feed>