OWASP - User contributions [en]

BASC 2018 Call For Papers

2018-08-15T14:17:33Z

Neil Smithline: Removed duplicate bullet (maybe the other bullets need a refresh - I see Google Glass in them)

{{2018_BASC:Header_Template | Home}}

== Submit Your Proposal ==

Please use [https://owasp.submittable.com/submit/118363/basc-cfp-boston-application-security-conference-october-27-2018 this form] to submit your proposal for a presentation.

Please use [https://owasp.submittable.com/submit/118366/basc-cfw-boston-application-security-conference-october-27-2018 this form] to submit your proposal for a workshop.

Deadline for proposals: September 28, 2018

Conference date: October 27, 2018

== About BASC ==

The [[Boston | OWASP Boston chapter]] would like to announce a call for papers and free workshops for the Boston Application Security Conference 2018 on October 27, 2018. This our eighth annual conference.

The OWASP BASC (Boston Application Security Conference) will be a free, one day, informal conference, aimed at increasing awareness and knowledge of application security in the greater Boston area. While many of the presentations will cover state-of-the-art application security concepts, the BASC is intended to appeal to a wide range of attendees. Application security professionals, professional software developers, software quality engineers, computer science students, and security software vendors will come to the BASC to learn, interact and hopefully enjoy themselves at the same time. We encourage local students, security professionals and academics to present papers as a way to gain exposure and experience in presenting at security conferences.

We expect over 200 attendees this year. Publicity includes the OWASP Boston wiki site (run by OWASP Foundation), OWASP Boston Meetup, OWASP Boston Linkedin group, OWASP Boston mailing list, Eventbrite and Twitter.
==Past conference presentations==
[[2017 BASC Presentations]] ·[[2016 BASC Presentations]] · [[2015 BASC Presentations]] · [[2014 BASC Presentations]] · [[2012 BASC Presentations]] · [[2011 BASC Presentations]] · [[2010 BASC Presentations]]

==Guidelines==
Last year, there were two tracks:

Track 1 - Basic/Current Application Security

Track 2 - Future / Advanced / New Research in Application security.

Each presentation will be 50 minutes.

We attract both people who are new to application security as well as people who are experienced in application security.

We encourage first time presenters: students, researchers, working application security folks etc. to submit presentations.
==Some Suggested Topics==
<div style="column-count:3;-moz-column-count:3;-webkit-column-count:3">
*Mobile app security, forensics

*Javascript servers, apps, frameworks: Node.js, Angular

*Language Framework (in)security – Hibernate, Grails, Ruby etc.

*Security for NFC, Bluetooth LE apps

*Google Glass app security

*OWASP ESAPI

*Measurable security - advanced threat modelling

*Web API security REST, JSON

*Application Architecture security

*Web security testing in a DevOps organization

*Building web app security expertise in engineering teams

*Conducting lightweight threat modeling

*Vulnerability Management - Process & Tools

*Developing your own web app security development standard

*Security test automation with OWASP ZAP and Zest scripting language

*Authentication & Enterprise Web Applications (incl. Federation, 2 Factor Auth, SSO)

*Open Source Identity Management

*Open Source Static Analysis

*Security Unit testing with Selenium

*Effective static code analysis tools</div>

==Submit==

Please use [https://owasp.submittable.com/submit/118363/basc-cfp-boston-application-security-conference-october-27-2018 this form] to submit your proposal for a presentation.

Please use [https://owasp.submittable.com/submit/118366/basc-cfw-boston-application-security-conference-october-27-2018 this form] to submit your proposal for a workshop.

Deadline for proposals: September 28, 2018

Conference date: October 27, 2018

If you have any questions, please email [mailto:boston@owasp.org boston@owasp.org].

{{2018_BASC:Footer_Template | Welcome}}

Clickjacking

2017-12-21T21:16:19Z

Neil Smithline: /* References */ added Mozilla's CSP/frame-ancestors

Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page. Thus, the attacker is "hijacking" clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both.

Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker.

=Examples=

For example, imagine an attacker who builds a web site that has a button on it that says "click here for a free iPod". However, on top of that web page, the attacker has loaded an iframe with your mail account, and lined up exactly the "delete all messages" button directly on top of the "free iPod" button. The victim tries to click on the "free iPod" button but instead actually clicked on the invisible "delete all messages" button. In essence, the attacker has "hijacked" the user's click, hence the name "Clickjacking".

One of the most notorious examples of Clickjacking was an attack against the [http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager06.html Adobe Flash plugin settings page]. By loading this page into an invisible iframe, an attacker could trick a user into altering the security settings of Flash, giving permission for any Flash animation to utilize the computer's microphone and camera.

Clickjacking also made the news in the form of a [http://shiflett.org/blog/2009/feb/twitter-dont-click-exploit Twitter worm]. This clickjacking attack convinced users to click on a button which caused them to re-tweet the location of the malicious page, and propagated massively.

There have also been clickjacking attacks abusing Facebook's "Like" functionality. [http://threatpost.com/en_us/blogs/facebook-jacking-scams-expand-060310 Attackers can trick logged-in Facebook users to arbitrarily like fan pages, links, groups, etc]

= Defending against Clickjacking =
There are two main ways to prevent clickjacking:
# Sending the proper Content Security Policy (CSP) frame-ancestors directive response headers that instruct the browser to not allow framing from other domains. (This replaces the older X-Frame-Options HTTP headers.)
# Employing defensive code in the UI to ensure that the current frame is the most top level window

For more information on Clickjacking defense, please see the the [[Clickjacking Defense Cheat Sheet]].

= References =
* [https://www.linkedin.com/pulse/20141202104842-120953718-why-am-i-anxious-about-clickjacking Why am I anxious about Clickjacking?]
: A Basic understanding of Clickjacking Attack

* https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors
: Mozilla developer resource on Content-Security-Policy frame-ancestors response header.

* https://developer.mozilla.org/en-US/docs/The_X-FRAME-OPTIONS_response_header
: Mozilla developer resource on the X-Frame-Options response header.

* [http://w2spconf.com/2010/papers/p27.pdf Busting Frame Busting: A study of clickjacking vulnerabilites on top sites]
: A study by the Stanford Web Security Group outlining problems with deployed frame busting code.

* [http://www.sectheory.com/clickjacking.htm Clickjacking, Sec Theory]
: A paper by Robert Hansen defining the term, its implications against Flash at the time of writing, and a disclosure timeline.

* [https://www.codemagi.com/blog/post/194 https://www.codemagi.com/blog/post/194]
: Framebreaking defense for legacy browsers that do not support X-Frame-Option headers.

* [[ClickjackFilter_for_Java_EE|Anti-clickjacking J2EE filter]]
: A simple J2EE servlet filter that sends anti-framing headers to the browser.

Clickjacking

2017-12-21T21:04:50Z

Neil Smithline: updated with CSP defense

Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page. Thus, the attacker is "hijacking" clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both.

Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker.

=Examples=

For example, imagine an attacker who builds a web site that has a button on it that says "click here for a free iPod". However, on top of that web page, the attacker has loaded an iframe with your mail account, and lined up exactly the "delete all messages" button directly on top of the "free iPod" button. The victim tries to click on the "free iPod" button but instead actually clicked on the invisible "delete all messages" button. In essence, the attacker has "hijacked" the user's click, hence the name "Clickjacking".

One of the most notorious examples of Clickjacking was an attack against the [http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager06.html Adobe Flash plugin settings page]. By loading this page into an invisible iframe, an attacker could trick a user into altering the security settings of Flash, giving permission for any Flash animation to utilize the computer's microphone and camera.

Clickjacking also made the news in the form of a [http://shiflett.org/blog/2009/feb/twitter-dont-click-exploit Twitter worm]. This clickjacking attack convinced users to click on a button which caused them to re-tweet the location of the malicious page, and propagated massively.

There have also been clickjacking attacks abusing Facebook's "Like" functionality. [http://threatpost.com/en_us/blogs/facebook-jacking-scams-expand-060310 Attackers can trick logged-in Facebook users to arbitrarily like fan pages, links, groups, etc]

= Defending against Clickjacking =
There are two main ways to prevent clickjacking:
# Sending the proper Content Security Policy (CSP) frame-ancestors directive response headers that instruct the browser to not allow framing from other domains. (This replaces the older X-Frame-Options HTTP headers.)
# Employing defensive code in the UI to ensure that the current frame is the most top level window

For more information on Clickjacking defense, please see the the [[Clickjacking Defense Cheat Sheet]].

= References =
* [https://www.linkedin.com/pulse/20141202104842-120953718-why-am-i-anxious-about-clickjacking Why am I anxious about Clickjacking?]
: A Basic understanding of Clickjacking Attack

* https://developer.mozilla.org/en-US/docs/The_X-FRAME-OPTIONS_response_header
: Mozilla developer resource on The X-Frame-Options response header.

* [http://w2spconf.com/2010/papers/p27.pdf Busting Frame Busting: A study of clickjacking vulnerabilites on top sites]
: A study by the Stanford Web Security Group outlining problems with deployed frame busting code.

* [http://www.sectheory.com/clickjacking.htm Clickjacking, Sec Theory]
: A paper by Robert Hansen defining the term, its implications against Flash at the time of writing, and a disclosure timeline.

* [https://www.codemagi.com/blog/post/194 https://www.codemagi.com/blog/post/194]
: Framebreaking defense for legacy browsers that do not support X-Frame-Option headers.

* [[ClickjackFilter_for_Java_EE|Anti-clickjacking J2EE filter]]
: A simple J2EE servlet filter that sends anti-framing headers to the browser.

File:OWASP-Top-10-2017-en.pdf

2017-11-20T17:46:42Z

Neil Smithline:

File:OWASP Top 10-2017 (en).pdf.pdf

2017-11-20T17:42:53Z

Neil Smithline: Neil Smithline uploaded a new version of File:OWASP Top 10-2017 (en).pdf.pdf

2017 Top 10

File:OWASP Top 10-2017 (en).pdf.pdf

2017-11-20T17:41:25Z

Neil Smithline: Neil Smithline uploaded a new version of File:OWASP Top 10-2017 (en).pdf.pdf

2017 Top 10

File:OWASP Top 10-2017 (en).pdf.pdf

2017-11-20T17:40:09Z

Neil Smithline: Neil Smithline uploaded a new version of File:OWASP Top 10-2017 (en).pdf.pdf

2017 Top 10

File:OWASP Top 10-2017 (en).pdf.pdf

2017-11-20T17:27:45Z

Neil Smithline: Neil Smithline uploaded a new version of File:OWASP Top 10-2017 (en).pdf.pdf

2017 Top 10

Category:OWASP Top Ten Project

2017-11-20T16:36:31Z

Neil Smithline: 2017 updates

Category:OWASP Top Ten Project

2017-11-20T16:33:36Z

Neil Smithline: Push 2017 T10

File:OWASP Top 10-2017 (en).pdf.pdf

2017-11-20T16:24:42Z

Neil Smithline:

2017 Top 10

Category:OWASP Top Ten Project

2017-11-19T23:07:58Z

Neil Smithline: updated license

Category:OWASP Top Ten Project

2017-11-19T22:59:01Z

Neil Smithline: 2017 translations note

2017-04-22T23:06:53Z

Neil Smithline:

{{Top_10_2013:TopTemplate
|usenext=2013NextLink
|next=A3-{{Top_10_2010:ByTheNumbers
|3
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A1-{{Top_10_2010:ByTheNumbers
|1
|year=2017
|language=en}}
|year=2017
|language=en
}}

{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
{{Top_10:SummaryTableTemplate|exploitability=2|prevalence=2|detectability=2|impact=1|year=2017|language=en}}
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
Consider anonymous external attackers, as well as authorized users, who may attempt to steal accounts from others. Also consider insiders wanting to disguise their actions.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
Attackers use leaks or flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to temporarily or permanently impersonate users.

</td>
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
Developers frequently build custom authentication and session management schemes, but building these correctly is hard. As a result, these custom schemes frequently have flaws in areas such as logout, create account, change password, forgot password, timeouts, remember me, secret question, account update, etc. Finding such flaws can sometimes be difficult, as each implementation is unique.

</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
Such flaws may allow some or even all accounts to be attacked. Once successful, the attacker can do anything the victim could do. Privileged accounts are frequently targeted.

</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
Consider the business value of the affected data or application functions.

Also consider the business impact of public exposure of the vulnerability.

</td>
{{Top_10_2010:SummaryTableEndTemplate|year=2017}}

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=1|risk=2|year=2017|language=en}}
Are session management assets like user credentials and session IDs properly protected? You may be vulnerable if:
# User authentication credentials aren’t properly protected when stored using hashing or encryption. See 2017-A6.
# Credentials can be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password, weak session IDs).
# Session IDs are exposed in the URL (e.g., URL rewriting).
# Session IDs are vulnerable to [[https://www.owasp.org/index.php/Session_fixation]] session fixation attacks.
# Session IDs don’t timeout, or user sessions or authentication tokens (particularly single sign-on (SSO) tokens) aren’t properly invalidated during logout.
# Session IDs aren’t rotated after successful login.
# Passwords, session IDs, and other credentials are sent over unencrypted connections. See 2017-A6.
See the [[ASVS]] requirement areas V2 and V3 for more details.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=2|risk=2|year=2017|language=en}}
The primary recommendation for an organization is to make available to developers:
<ol>
<li>'''A single set of strong authentication and session management controls.''' Such controls should strive to:
<ol type="a">
<li>meet all the authentication and session management requirements defined in OWASP’s [https://www.owasp.org/index.php/ASVS Application Security Verification Standard (ASVS)] areas V2 (Authentication) and V3 (Session Management).</li>
<li>have a simple interface for developers. Consider the [https://static.javadoc.io/org.owasp.esapi/esapi/2.1.0.1/org/owasp/esapi/Authenticator.html ESAPI Authenticator and User APIs] as good examples to emulate, use, or build upon.</li>
</ol>
</li>
<li>Strong efforts should also be made to avoid XSS flaws which can be used to steal session IDs. See 2017-A3.</li>
</ol>
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=3|risk=2|year=2017|language=en}}
'''Scenario #1:''' Airline reservations application supports URL rewriting, putting session IDs in the URL:
{{Top_10_2010:ExampleBeginTemplate|year=2017}}<nowiki>h</nowiki>ttp://example.com/sale/saleitems<span style="color: red;">?sessionid=268544541</span>&dest=Hawaii
{{Top_10_2010:ExampleEndTemplate|year=2017}}
An authenticated user of the site wants to let their friends know about the sale. User e-mails the above link without knowing they are also giving away their session ID. When the friends use the link they use user’s session and credit card.
'''Scenario #2''': Application’s timeouts aren’t set properly. User uses a public computer to access site. Instead of selecting “logout” the user simply closes the browser tab and walks away. An attacker uses the same browser an hour later, and that browser is still authenticated.
'''Scenario #3''': An insider or external attacker gains access to the system’s password database. User passwords are not properly hashed and salted, exposing every users’ password.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=4|risk=2|year=2017|language=en}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate|year=2017}}<br/>
For a more complete set of requirements and problems to avoid in this area, see the [[ASVS | ASVS requirements areas for Authentication (V2) and Session Management (V3)]].
* [[Authentication_Cheat_Sheet | OWASP Authentication Cheat Sheet]]
* [[Forgot_Password_Cheat_Sheet | OWASP Forgot Password Cheat Sheet]]
* [[Password_Storage_Cheat_Sheet|OWASP Password Storage Cheat Sheet]]
* [[Session_Management_Cheat_Sheet | OWASP Session Management Cheat Sheet]]
* [[Testing_for_authentication | OWASP Testing Guide: Chapter on Authentication]]

{{Top_10_2010:SubSubsectionExternalReferencesTemplate|year=2017|language=en}}
* [http://cwe.mitre.org/data/definitions/287.html CWE Entry 287 on Improper Authentication]
* [http://cwe.mitre.org/data/definitions/384.html CWE Entry 384 on Session Fixation]

{{Top_10_2013:BottomAdvancedTemplate
|type={{Top_10_2010:StyleTemplate}}
|usenext=2013NextLink
|next=A3-{{Top_10_2010:ByTheNumbers
|3
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A1-{{Top_10_2010:ByTheNumbers
|1
|year=2017
|language=en}}
|year=2017
|language=en
}}