OWASP - User contributions [en]

Jacksonville

2019-08-25T19:10:48Z

Nawwar: /* Sponsorship/Membership */ Name spelling correction

{{Chapter Template|chaptername=Jacksonville|extra=The chapter leaders are [mailto:kevin.johnson@owasp.org Kevin Johnson] and [mailto:larry.franklin@owasp.org Larry Franklin].
|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Jacksonville|emailarchives=http://lists.owasp.org/pipermail/owasp-Jacksonville}}

'''Upcoming Meetings'''

Monthly OWASP Jax meetings will be held on the second Monday of the month, unless otherwise stated. The meeting location will be held in the Secure Ideas Headquarters training room at 3412 Kori Rd, Jacksonville, Fl 32257. The start time is 6:30 with a short introduction and presentations beginning at 7:00 until NLT 8:30pm. All are welcome to attend by registering at the following link; https://www.meetup.com/OWASP-Jacksonville-Chapter/. Please register by the Friday prior to the meeting.

June 11, 2018 - Guest speaker will be Oleg Laskin. Oleg, will be presenting on the tools used during the testing of web applications, with an intro to applications like ZAP and Burp Suite.

July 9, 2018 - **Cancelled**

August 06, 2018 - Keith Perry.

September 10, 2018 - Guest speakers Nathan Sweeney and Mic Whitehorn-Gillam, topic will be a discussion about testing an Application vs API
Video link: https://www.youtube.com/watch?v=pyQDO6S9vQ4

October 8, 2018 - Brandi Kiehl
Topic: WordClouds

November 12, 2018 - Dr Johannes Ullrich
Topic: Nation State Level Honeypotting: Emulating Vulnerable Web Applications at Scale Video link: https://youtu.be/2anqrtfJ1nA

December 10 - OWASP Jax social ** Cancelled **

January 14, 2019 - Guest Speaker Oleg Laskin , Password Cracking https://www.youtube.com/watch?v=Sz2IayEfuBg&t=741s

February 11, 2019 - Guest Speaker Michael Marbut, Everything you want to know about passwords but we're too afraid to ask: a beginners guide to password hashing Video link : https://youtu.be/prhE150EiI4

March 11, 2019 - Guest Speaker David Fekke, this presentation will cover the BlackBerry Dynamics framework, what it can provide for mobile and enterprise security. This presentation will include a demo of a iOS application built with BlackBerry Dynamics. https://www.eventbrite.com/e/owaspjax-monthly-meeting-tickets-55975263520

April 8, 2019 - Nawwar Kabbani - Modern authentication and authorization with OAUTH 2.0 and OpenID Connect

May 13, 2019 - Guest Speaker Lev Shaket - GatsbyJs and AWS Lambda // Statically generate passphrases with dreidelware.org

June 10, 2019 - Guest speaker Travis Phillips - Pwntools

Be sure to sign up at our Meetup page https://www.meetup.com/OWASP-Jacksonville-Chapter/

July 8, 2019 - Kevin Johnson CEO and owner of Secure Ideas LLC, - OWASP WishBook, an incite into OWASP projects and how you can contribute.

August 12, 2019 - Martin Knobloch Chairman of the Board OWASP Foundation - Security in a DevOps world with OWASP tools & guides

September 9, 2019 - Michael Marbut - Interactive presentation on OWASP's Juice Shop.

October 14,2019 - Michael Dimmett - "How the web works" and using chrome development tools to reverse engineer undocumented parts the youtube embed api.

November 11, 2019 - Larry Franklin OWASP JAX Chapter Leader - Open discussion on Security risk associated with Web application development and how to manage them effectively.

''Please join our Google groups at https://groups.google.com/a/owasp.org/forum/#!forum/jacksonville-chapter for topic discussions after the meetings, and for any future happenings in our OWASP group.''

'''Our Sponsors:'''

Secure Ideas

Robert Half Technology Jacksonville
[[Category:OWASP Chapter]]

SecureFlag

2019-04-30T18:33:14Z

Nawwar: /* ASP.NET */ Update ASP.NET section with more details and an alternative example.

{{taggedDocument
| type=old
| lastRevision=2015-12-14
| comment=References out-of-date platforms and environments.
}}

= Overview =

The secure flag is an option that can be set by the application server when sending a new cookie to the user within an HTTP Response. The purpose of the secure flag is to prevent cookies from being observed by unauthorized parties due to the transmission of a the cookie in clear text. 

To accomplish this goal, browsers which support the secure flag will only send cookies with the secure flag when the request is going to a HTTPS page. Said in another way, the browser will not send a cookie with the secure flag set over an unencrypted HTTP request. 

By setting the secure flag, the browser will prevent the transmission of a cookie over an unencrypted channel. 

= Setting the Secure Flag =

Following sections describes setting the Secure Flag in respective technologies.

== Java ==

=== Servlet 3.0 (Java EE 6) ===
Sun Java EE supports secure flag in Cookie interface since version 6 (Servlet class version 3)[http://java.sun.com/javaee/6/docs/api/javax/servlet/http/Cookie.html#setSecure%28boolean%29], also for session cookies (JSESSIONID)[http://java.sun.com/javaee/6/docs/api/javax/servlet/SessionCookieConfig.html#setSecure%28boolean%29]. Methods ''setSecure'' and ''isSecure'' can be used to set and check for secure value in cookies.

==== web.xml ====
Servlet 3.0 (Java EE 6) introduced a standard way to configure secure attribute for the session cookie, this can be done by applying the following configuration in web.xml
<session-config>
<cookie-config>
<secure>true</secure>
</cookie-config>
</session-config>

=== Tomcat ===
In '''Tomcat 6''' if the first request for session is using ''https'' then it automatically sets secure attribute on session cookie.

=== Setting it as a custom header ===
For '''older versions''' the workaround is to rewrite JSESSIONID value using and setting it as a custom header. The drawback is that servers can be configured to use a different session identifier than JSESSIONID.

String sessionid = request.getSession().getId();
response.setHeader("SET-COOKIE", "JSESSIONID=" + sessionid + "; secure");

=== Environment consideration ===

With this flag always set, sessions won't work in environments(development/test/etc.) that may use http. SessionCookieConfig [http://java.sun.com/javaee/6/docs/api/javax/servlet/SessionCookieConfig.html#setSecure%28boolean%29] interface or setting custom header[https://www.owasp.org/index.php/SecureFlag#Setting_it_as_a_custom_header] trick can be leveraged to configure setting of this flag differently for each environment and can be driven by application configuration.

== ASP.NET ==

Set the following in Web.config:
<httpCookies requireSSL="true" />

For some objects that have a requireSSL property, like the forms Authentication Cookie, set the requireSSL="true" flag in the ''web.config'' for that specific element. For example:
<code><authentication mode="Forms"></code>
<code><forms loginUrl="member_login.aspx"</code>
<code>cookieless="UseCookies"</code>
<code>'''requireSSL="true"'''</code>
<code>path="/MyApplication" /></code>
<code></authentication></code>
Which will enable the secure flag on the Forms Authentication cookie, as well as checking that the http request is coming to the server over SSL/TLS connection. Note that in case TLS is offloaded to a load balancer, the requireSSL solution wouldn't work.

Alternatively, the cookies can be set to secure programmatically using the following code by adding a EndRequest event handler to the Global.asax.cs file:
protected void Application_EndRequest(Object sender, EventArgs e) {
// Iterate through any cookies found in the Response object.
foreach (string cookieName in Response.Cookies.AllKeys) {
Response.Cookies[cookieName]?.Secure = true;
}
}

== PHP ==

For session cookies managed by PHP, the flag is set either permanently in php.ini [http://php.net/manual/en/session.configuration.php#ini.session.cookie-secure PHP manual on ''SecureFlag''] through the parameter:
session.cookie_secure = True
or in and during a script via the function [http://pl.php.net/manual/en/function.session-set-cookie-params.php]:
void session_set_cookie_params ( int $lifetime [, string $path [, string $domain
[, bool $secure= false [, bool $httponly= false ]]]] )
For application cookies a parameter in setcookie() sets Secure flag [http://pl.php.net/setcookie]:
bool setcookie ( string $name [, string $value [, int $expire= 0 [, string $path
[, string $domain [, bool $secure= false [, bool $httponly= false ]]]]]] )

= Testing for the Secure Flag =

Verifying that a web site sets this flag on any particular cookie is easy. Using an intercepting proxy, like [[ZAP]], you can capture each response from the server and examine any Set-Cookie headers it includes to see if the secure flag is set on the cookie.

= Related Articles =
* [[Testing for cookies attributes (OTG-SESS-002)|Testing for Cookie Attributes]]
* http://www.troyhunt.com/2011/11/owasp-top-10-for-net-developers-part-9.html

[[Category:Control]]

How to write insecure code

2017-05-15T17:14:30Z

Nawwar: "Testing is overrated"

__NOTOC__

=HOW TO WRITE INSECURE CODE=

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.org/root/phun/unmaintain.html one page version more readable]. Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

; '''Be a shark'''
: Always be on the move. Leave security problems to operations staff.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Code wants to be free!'''
: Drop your source code into repositories that are accessible by all within the company. This also prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Authentication==

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.
'''Just use a hash'''

Salt is for pigs. Its way too much work to salt and hash passwords. Besides, only the application can get to the database and hashes are one way trap doors, so why would you need it?
; '''Sessions are inherently secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

==Authorization==

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

; '''Optimize the developer... always'''
: Each developer, independent of one another, must decide where authorization decision and enforcement is made.

; '''Trust the client'''
: RIA clients and fat clients that use remote services can make decisions about what the end-user can or can't see.

; '''Volunteer to authorize access to other systems'''
: When a service you are calling, for example, has inappropriate access controls just be nice and live with it. After all it will be your fault when a direct object reference permits any user of your system to see any data on their service. Should that happen, it will be a chance for you to show your dedication when you're up at 3 AM on a Saturday morning sorting out a breach.

==Policy==

; '''Forget about it'''
: Policy can't be known until the user requests arrive. Put authorization logic where you see fit. Sometimes you need to roll it into the UI. Sometimes it's in the data layer. Sometimes it's both.
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think that security requirements can be known at design time and expressed in a runtime-readable/declarative format.

; '''The tool knows how to do it'''
: Let your automated tools dictate your security requirements. Tailoring is for suckers.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

; '''Trust the client'''
: If the client doesn't, by design, produce wacky encoding, for example, then wacky encoding isn't a threat.

==Documentation==

; '''If you can build it and it appears to work then why describe it?'''
: The most successful applications do not waste time with requirements, security or otherwise. Optimize the development by keeping the developers from having to read.

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==
; '''Testing is overrated'''
: Testing is expensive and time-consuming. Just code and ship immediately. The market wants your newest release yesterday. If anything is broken, your loyal users will let you know.
; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.
'''Test with only one browser'''

After all, they all work the same way and follow standards and never differ in terms of security.
; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

; '''Don't worry about using the latest version of components'''
: Just because a library has known vulnerabilities doesn't mean it's not safe to use. If there's no proof that *my* application is vulnerable then you're just wasting my time.

==Culture==

; "I got a security approval"
: So what if it was several years ago, it's basically the same code anyway.

; "Security has to *prove* it before I do anything"
: So what if you exploited my application, you cheated by using hacking

; "Hello, this is an internal application, so security doesn't matter"
: We have firewalls and stuff [[Category:How To]]

== DevOps ==
'''Automation is enough security'''

Forget about integrity, if we have a problem with a node, all we need to do is kill it and stand another up

'''Automated Scanning'''

It just creates more garbage nobody is going to read anyways

'''Access Control on DevOps systems'''

IAM roles and how keys are managed don't matter much, we can just check them right into GitHub and it'll be lost in a world of anonymity. Hell, we can even put all our code there so we can just pull it from anywhere.

'''Static Analysis'''

See automated scanning

'''Dynamic Analysis'''

See automated scanning

'''Dependency checking'''

No one would ever think to put a payload in a library, and hey, the signature on libraries are probably always there.

'''Auditing is a waste of money'''

There is no reason to check actual configurations written when we are using playbooks and configuration automation the tell us a node started out with a good configuration. Why would it ever change? Also see Automation is enough security

'''We'll never lose control of our nodes'''

Let's just write that root key down on paper and share it with the team. Nobody would ever leak it and create a botnet on our dollar.

'''CORS'''

The cloud is all about sharing! Let's CORS * everything!

'''Logging Services'''

We're using other peoples infrastructure anyways, why bother with logs or alerts? It's just a waste of time

Testing for logout functionality (OTG-SESS-006)

2015-10-08T20:22:29Z

Nawwar: /* References */ fixing a link

{{Template:OWASP Testing Guide v4}}

== Summary ==
Session termination is an important part of the session lifecycle. Reducing to a minimum the lifetime of the session tokens decreases the likelihood of a successful session hijacking attack. This can be seen as a control against preventing other attacks like Cross Site Scripting and Cross Site Request Forgery. Such attacks have been known to rely on a user having an authenticated session present. Not having a secure session termination only increases the attack surface for any of these attacks.

A secure session termination requires at least the following components:

* Availability of user interface controls that allow the user to manually log out.
* Session termination after a given amount of time without activity (session timeout).
* Proper invalidation of server-side session state.

There are multiple issues which can prevent the effective termination of a session. For the ideal secure web application, a user should be able to terminate at any time through the user interface. Every page should contain a log out button on a place where it is directly visible. Unclear or ambiguous log out functions could cause the user not trusting such functionality.

Another common mistake in session termination is that the client-side session token is set to a new value while the server-side state remains active and can be reused by setting the session cookie back to the previous value. Sometimes only a confirmation message is shown to the user without performing any further action. This should be avoided.

Some web application frameworks rely solely on the session cookie to identify the logged-on user. The user's ID is embedded in the (encrypted) cookie value. The application server does not do any tracking on the server-side of the session. When logging out, the session cookie is removed from the browser. However, since the application does not do any tracking, it does not know whether a session is logged out or not. So by reusing a session cookie it is possible to gain access to the authenticated session. A well-known example of this is the Forms Authentication functionality in ASP.NET.

Users of web browsers often don't mind that an application is still open and just close the browser or a tab. A web application should be aware of this behavior and terminate the session automatically on the server-side after a defined amount of time.

The usage of a single sign-on (SSO) system instead of an application-specific authentication scheme often causes the coexistence of multiple sessions which have to be terminated separately. For instance, the termination of the application-specific session does not terminate the session in the SSO system. Navigating back to the SSO portal offers the user the possibility to log back in to the application where the log out was performed just before. On the other side a log out function in a SSO system does not necessarily cause session termination in connected applications.

== How to Test ==
'''Testing for log out user interface:''' 
Verify the appearance and visibility of the log out functionality in the user interface. For this purpose, view each page from the perspective of a user who has the intention to log out from the web application.

'''Result Expected:''' 
There are some properties which indicate a good log out user interface:
* A log out button is present on all pages of the web application.
* The log out button should be identified quickly by a user who wants to log out from the web application.
* After loading a page the log out button should be visible without scrolling.
* Ideally the log out button is placed in an area of the page that is fixed in the view port of the browser and not affected by scrolling of the content.

'''Testing for server-side session termination:''' 
First, store the values of cookies that are used to identify a session. Invoke the log out function and observe the behavior of the application, especially regarding session cookies. Try to navigate to a page that is only visible in an authenticated session, e.g. by usage of the back button of the browser. If a cached version of the page is displayed, use the reload button to refresh the page from the server. If the log out function causes session cookies to be set to a new value, restore the old value of the session cookies and reload a page from the authenticated area of the application. If these test don't show any vulnerabilities on a particular page, try at least some further pages of the application that are considered as security-critical, to ensure that session termination is recognized properly by these areas of the application.

'''Result Expected:''' 
No data that should be visible only by authenticated users should be visible on the examined pages while performing the tests. Ideally the application redirects to a public area or a log in form while accessing authenticated areas after termination of the session. It should be not necessary for the security of the application, but setting session cookies to new values after log out is generally considered as good practice.

'''Testing for session timeout:''' 
Try to determine a session timeout by performing requests to a page in the authenticated area of the web application with increasing delays. If the log out behavior appears, the used delay matches approximately the session timeout value.

'''Result Expected:''' 
The same results as for server-side session termination testing described before are excepted by a log out caused by an inactivity timeout.

The proper value for the session timeout depends on the purpose of the application and should be a balance of security and usability. In a banking applications it makes no sense to keep an inactive session more than 15 minutes. On the other side a short timeout in a wiki or forum could annoy users which are typing lengthy articles with unnecessary log in requests. There timeouts of an hour and more can be acceptable.

'''Testing for session termination in single sign-on environments (single sign-off):''' 
Perform a log out in the tested application. Verify if there is a central portal or application directory which allows the user to log back in to the application without authentication. Test if the application requests the user to authenticate, if the URL of an entry point to the application is requested. While logged in in the tested application, perform a log out in the SSO system. Then try to access an authenticated area of the tested application.

'''Result Expected:''' 
It is expected that the invocation of a log out function in a web application connected to a SSO system or in the SSO system itself causes global termination of all sessions. An authentication of the user should be required to gain access to the application after log out in the SSO system and connected application.

==Tools==
* "Burp Suite - Repeater" - http://portswigger.net/burp/repeater.html

== References ==
'''Whitepapers'''
* "The FormsAuthentication.SignOut method does not prevent cookie reply attacks in ASP.NET applications" - https://support.microsoft.com/en-us/kb/900111
* "Cookie replay attacks in ASP.NET when using forms authentication" - https://www.vanstechelman.eu/content/cookie-replay-attacks-in-aspnet-when-using-forms-authentication

Testing for Session puzzling (OTG-SESS-008)

2015-08-17T18:50:59Z

Nawwar: /* Summary */ typo: by -> but

{{Template:OWASP Testing Guide v4}}

== Summary ==

Session Variable Overloading (also known as Session Puzzling) is an application level vulnerability which can enable an attacker to perform a variety of malicious actions, including but not limited to:
* Bypass efficient authentication enforcement mechanisms, and impersonate legitimate users.
* Elevate the privileges of a malicious user account, in an environment that would otherwise be considered foolproof.
* Skip over qualifying phases in multi-phase processes, even if the process includes all the commonly recommended code level restrictions.
* Manipulate server-side values in indirect methods that cannot be predicted or detected.
* Execute traditional attacks in locations that were previously unreachable, or even considered secure.

This vulnerability occurs when an application uses the same session variable for more than one purpose. An attacker can potentially access pages in an order unanticipated by the developers so that the session variable is set in one context and then used in another.

For example, an attacker could use session variable overloading to bypass authentication enforcement mechanisms of applications that enforce authentication by validating the existence of session variables that contain identity–related values, which are usually stored in the session after a successful authentication process. This means an attacker first accesses a location in the application that sets session context and then accesses privileged locations that examine this context.

For example - an authentication bypass attack vector could be executed by accessing a publicly accessible entry point (e.g. a password recovery page) that populates the session with an identical session variable, based on fixed values or on user originating input.

==How to Test==
=== Black Box Testing ===

This vulnerability can be detected and exploited by enumerating all of the session variables used by the application and in which context they are valid. In particular this is possible by accessing a sequence of entry points and then examining exit points. In case of black box testing this procedure is difficult and requires some luck since every different sequence could lead to a different result.

====Examples====

A very simple example could be the password reset functionality that, in the entry point, could request the user to provide some identifying information such as the username or the e-mail address. This page might then populate the session with these identifying values, which are received directly from the client side, or obtained from queries or calculations based on the received input. At this point there may be some pages in the application that show private data based on this session object. In this manner the attacker could bypass the authentication process.

=== Gray Box testing ===

The most effective way to detect these vulnerabilities is via a source code review.

==References==
'''Whitepapers''' 
* Session Puzzles: http://puzzlemall.googlecode.com/files/Session%20Puzzles%20-%20Indirect%20Application%20Attack%20Vectors%20-%20May%202011%20-%20Whitepaper.pdf
* Session Puzzling and Session Race Conditions: http://sectooladdict.blogspot.com/2011/09/session-puzzling-and-session-race.html

==Remediation==

Session variables should only be used for a single consistent purpose.

Hibernate

2015-03-11T17:07:54Z

Nawwar: /* Persisting tainted data */ correcting inconsistent variable name

== Status ==
'''In progress'''

== Before you begin ==
Since ORM architecture isn't obvious, this document will explain some important things you need to know in order to analyze a Hibernate application in a security context. This document assumes some SQL and database knowledge.

=== A note about SQL injection ===
Since it is the hot topic, I will address it now but discuss in detail later.
* Hibernate does not grant immunity to SQL Injection, one can misuse the api as they please.
* There is nothing special about HQL (Hibernates subset of SQL) that makes it any more or less susceptible.
* Functions such as createQuery(String query) and createSQLQuery(String query) create a Query object that will be executed when the call to commit() is made. If the query string is tainted you have sql injection. The details of these functions are covered later.

== Overview ==

=== The problem Hibernate addresses ===
In object oriented systems, we represent entities as objects, and use a database to persist those objects. Generally these objects are considered non-scalar values (non-primitive types).
But many databases can only store and manipulate scalar values organized in tables.
The crux of the problem is translating those objects to forms which can be stored in the database, and which can later be retrieved easily, while preserving the properties of the objects and their relationships; these objects are then said to be persistent.
Hibernate attempts to address this problem with Object/Relational Mapping (O/R M) by mapping attributes of objects we wish to persist to columns of a database.

[http://en.wikipedia.org/wiki/Object-relational_mapping See original article. ]

=== How it works ===
* Usually Hibernate applications use [http://en.wikipedia.org/wiki/JavaBean JavaBeans] style [http://en.wikipedia.org/wiki/Plain_Old_Java_Object POJOs] to represent objects we want to persist in a database.
* These objects should have an identifier property (i.e private class variable) used to represent it's primary key value in the database.
* This identifier will be mapped in a hibernate mapping file, usually with the default extension .hbm.xml, you will see this mapping in the <id> element. This file will also map all other object properties we wish to preserve to columns in a database table, along with their data types and other stuff.
* Once objects are mapped, Hibernate provides the mechanism for you to store and access them via org.hibernate.Session and org.hibernate.Transaction objects.
* The Session object has methods to save() objects to a session, load() objects from a database and createQuery()s to be executed against the database.
* The Transaction object often wraps a database transaction, allowing one to begin() transactions, commit() changes, and rollback() to a previous state.
* Other classes worth mentioning: SessionFactory, TransactionFactory, and Query.
* Hibernate's main configuration file, extension .cfg.xml, provides basic setup for things like datasource, dialect, mapping files, etc.
[http://www.owasp.org/index.php/Hibernate/config-example See this configuration example]

=== Jargon ===
*'''Transient''' - The instance is not associated with a Session, has no persistent representation in the database and no identifier assigned. An object that has just been instantiated with the new operator is said to be transient.
*'''Persistent''' - Is associated with a Session, has a representation in the database and has been assigned an identifier. Hibernate synchronizes changes on a persistent object with its representation in the database when it completes a unit of work.
*'''Detatched''' - was once in a persistent state, but its session has been closed. The reference is still valid and the object may be modified and even reattached to a new session later.

=== Hitting the database ===
The Session object represents the main interface or ''conversation'' between Java and Hibernate. A Session is used for a single request, or unit of work. To make an object persistent, it must first be associated with a Session. But where does the session come from? Hibernate's Configuration object instantiates a SessionFactory (Configuration.buildSessionFactory()) which is an expensive, immutable, thread safe object intended to be shared by all application threads. Threads that service client requests must obtain a Session from the factory by calling SessionFactory.getCurrentSession() or SessionFactory.openSession().

Anyways, a Session is NOT thread safe and there are associated concurrency issues discussed in [https://www.owasp.org/index.php/Hibernate-Guidelines#Session_and_Concurrency_issues this section] of the Hibernate Guidelines page. Once an object is associated with a Session we can begin a transaction. All database communication must occur within the scope of a transaction. A transaction starts with a call to Transaction.begin() or Session.beginTransaction() and ends with a call to Transaction.commit().

To actually build queries, store and retrieve data we mostly use methods in the Session class. For example, load() will instantiate a class object, and load the state from the database into the instance. Session.createQuery() will return a Query object which has many methods with which to operate on this query string. Query.setParameter(), setFloat(), and others act similar to prepared statements. You can also simply call Query.executeUpdate() to execute the query.

''Ok, why don't we just see what it looks like.''
Example1
<pre>
Session sess = factory.openSession();
Transaction tx;
try {
tx = sess.beginTransaction();
Query q = sess.createQuery("from DomesticCat cat where cat.name = ?");
q.setString(0, "Izi");
tx.commit();
}
catch (Exception e) {
if (tx!=null) tx.rollback();
throw e;
}
finally {
sess.close();
}
</pre>
''Another simple example using HQL and named parameters...this time we have a helper class to obtain a Session''
<pre>
Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction(); //All database communication occurs within the scope of a transaction

Person aPerson = (Person) session
.createQuery("select p from Person p left join fetch p.events where p.id = :pid")
.setParameter("pid", personId);

session.getTransaction().commit();
</pre>

== Security Implications ==
These issues are discussed in context on this page and are also listed in [https://www.owasp.org/index.php/Hibernate-Guidelines#Important this section] of Hibernate Guidelines.

* No communication with the database should occur outside of a database transaction. Doing so will probably result in synchronization issues. Transactions should also not encompass user think time. Details are of how it's done is discussed in the [http://www.owasp.org/index.php/Hibernate#Defining_Transaction_Bounds Defining Transaction Bounds section] of this page.

* createQuery() can easily be passed a tainted SQL or HQL string, dialect is irrelevant. The proper way to construct a sql string hibernate style is to use Query and SQLQuery's setParameter(), setString(), setXXX() methods for named parameter and placeholder binding. Just like prepared statements. Details are discussed in the [http://www.owasp.org/index.php/Hibernate#Creating_Queries Creating Queries section] of this page.

* Persisting tainted objects is stored xss. Since stored XSS is generally hard to find with static tools, it is best to sanitize all data going in rather than waiting for it to show up on a jsp somewhere. Details of these functions are discussed in the [http://www.owasp.org/index.php/Hibernate#Persisting_Tainted_Data Persisting Tainted Data section] of this page.

* An application should rollback and discard Session instance on error. So if the Session throws an exception, the catch block should have rollback() and finally should call Session.close(). This applies to any SQLException. Pretty cut and dry, see Example1 above.

* You may not mix and match JDBC-style parameters ("?") and named parameters (:namedparam) in the same query.
<pre>
Person aPerson = (Person) session
.createQuery("select :somenamedparameter from ? where x = :someothernamedparameter");
</pre>
* Transaction.setTimeout(int) should be called to ensure that misbehaving transactions do not tie up resources in definitely.
<pre>
Session sess = factory.openSession();
try {
//set transaction timeout to 3 seconds
sess.getTransaction().setTimeout(3);
sess.getTransaction().begin();
// do some work
...
</pre>

== Defining Transaction Bounds ==
Usually, ending a Session involves four distinct phases:

* flush the session
* commit the transaction
* close the session
* handle exceptions

Note:
* If commit() is present, no need to call flush() as it does this already.
* Most database communication methods only propagate exceptions if they're outside the scope of the session. (this is an assumption based on the many functions whose source I've examined, I won't be perusing the entire api source to back this assumption)

Consider this example:
<pre>
// Non-managed environment idiom
Session sess = factory.openSession();
Transaction tx = null;
try {
tx = sess.beginTransaction();
// do some work
...
tx.commit();
}
catch (RuntimeException e) {
if (tx != null) tx.rollback();
throw e; // or display error message
}
finally {
sess.close();
}
</pre>
Most Common Functions:

* Session.beginTransaction() - begin transaction (doh)
* Session.getTransaction() - begin transaction
* Session.flush() - end transaction
* Session.close() - end session
* Transaction.begin() - begin transaction
* Transaction.commit() - end transaction
* Transaction.rollback() -

== Creating, manipulating and executing queries ==
* The Session interface defines methods that create Query and SQLQuery objects - these are the methods we care about because they allow the developer to construct query strings (as opposed to letting Hibernate perform the sql operations).
* The Query/SQLQuery objects are mutable and executable, but are not actually SUNK until Transaction.commit(), or Query.executeUpdate() is called. However, I think it is best that we flag functions that create and construct Query objects as they would be in direct contact with tainted data.
* Once a Query or SQLQuery object is obtained from the Session, the parameters of its sql string should be set using the setter functions like setParameter(), the setters are listed here. These setters check for type mismatch, or guess the type, then check for positional mismatch and named parameter mismatch so they're pretty safe me thinks. Concatenating tainted parameters using the '+' operator, on the other hand, would be equivalent to mis-using a prepared-statement.

Consider this example:
<pre>
String table = (String) req.getParameter("table");//obviously retarded
String parameter1 = request.getParameter("param1");

Session session = sessionFactory.getCurrentSession();
try{
session.beginTransaction();
SQLQuery query = session.createSQLQuery("SELECT * FROM " + table + "WHERE stuff= ?"); /*B00*/
query.setParameter(0, parameter1); /*YAY*/
session.getTransaction().commit();
} catch (Exception e) {}
session.close();//omfg no rollback?
</pre>
Most Common Functions:

* Session.createSQLQuery(String queryString) - creates a Query with given SQL string - technically executed on commit() or flush() but this function is more directly related to the taint source.
* Session.createQuery(String queryString) - creates Query with given HQL string.
* Session.createFilter(Object collection, String queryString) - creates a Query with filter string.
* Query.setParameter() - variations on this binds parameters to "?" and ":namedparams"
* Query.executeUpdate() -
* Query.getQueryString() -

==== More Examples ====

Using queries from other Queries:
<pre>
String sql;

session.beginTransaction();
Query q1 = session.createQuery(taintSQL); //pretend taintSQL came from unchecked input
sql = q1.getQueryString(); //get taintSQL
session.getTransaction.commit();

session.beginTransaction();
Query q2 = new QueryImpl(sql, session, parameterMetadata); //reuse taintSQL w/o validation
session.getTransaction.commit(); //evil prevails
session.close();
</pre>
Using executeUpdate()
<pre>
public void executeUpdateHQL(Session session, String evil)//a few calls deep from where evil became tainted
{
Query query = session.createQuery(evil); /*B00*/
query.setString("name","Evil");
query.setString("newName","EEvil"); //these don't matter if the sql is already evil
int rowCount = query.executeUpdate(); /*B00*/
System.out.println("Rows affected: " + rowCount);

//See the results of the update and some other random stuff
query = session.createQuery("from Supplier");
List results = query.list();

displaySupplierList(results);
}
</pre>
named parameter (preferred)
<pre>
Query q = sess.createQuery("from DomesticCat cat where cat.name = :name");
q.setString("name", "Fritz");
Iterator cats = q.iterate();
</pre>
positional parameter
<pre>
Query q = sess.createQuery("from DomesticCat cat where cat.name = ?");
q.setString(0, "Izi");
Iterator cats = q.iterate();
</pre>
named parameter list
<pre>
List names = new ArrayList();
names.add("Izi");
names.add("Fritz");
Query q = sess.createQuery("from DomesticCat cat where cat.name in (:namesList)");
q.setParameterList("namesList", names);
List cats = q.list();
</pre>
Executing a bunch of actions (relevant fns listed in the excel sheet)
<pre>
private List executions;
....
executions = new LinkedList();
....
private void executeActions(List list) throws HibernateException {
for ( Iterator execItr = list.iterator(); execItr.hasNext(); ) {
execute( (Executable) execItr.next() );
}
list.clear();
session.getBatcher().executeBatch();
}
public void execute(Executable executable) {
final boolean lockQueryCache = session.getFactory().getSettings().isQueryCacheEnabled();
if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
executions.add( executable );
}
if (lockQueryCache) {
session.getFactory()
.getUpdateTimestampsCache()
.preinvalidate( executable.getPropertySpaces() );
}
executable.execute();
}
</pre>

== Persisting tainted data ==

* Assume persistent objects have JavaBeans style setter methods as this is most common practice. When these setters are called with tainted parameters consider this object to be tainted.
* We should flag all functions where tainted objects are made persistent. Although most documents will define Session.save() or Session.persist() as making an object persistent, it is actually PENDING until a call to Transaction.commit() is made. Whether or not we want to flag the saves, or the commits is up to scan dev - keep in mind that if we're flagging commit() we must first decide that the code between Transaction.begin() or Session.beginTransaction() and Transaction.commit() contains eevil.
* The only associated cwe I can think of right now is stored xss.

Consider this example:
<pre>
Session session = sessionFactory.getCurrentSession();
String firstname = request.getParameter("firstname");
String lastname = request.getParameter("lastname");

try{
Transaction tx = session.beginTransaction();

Person thePerson = session.load(Person.class, new Long(69));//loading an already persistent object
thePerson.setFirstname(firstname);// then adding tainted data to it
thePerson.setLastname(lastname);
session.save(thePerson); //persisting our changes

session.getTransaction().commit();
} catch (Exception e) {
if (tx!=null) tx.rollback();
throw e;
}
session.close();
</pre>
Most Common Functions:

* Session.save(Object object) - save object to the session, object should not contain tainted data.
* Session.persist(Object object) -
* Session.void replicate(Object object, ReplicationMode?? replicationMode) -
* Session.void saveOrUpdate(Object object) -
* Session.update(Object object)() -
* Session.evict(Object object)() - remove instance from session cache
* Session.clear() - evict all loaded instances
* Session.load(Class theClass, Serializable id) - gets an object from the db for you to manipulate.

[[Category:Hibernate]]
[[Category:OWASP Java Project]]
[[Category:Java]]