The document discusses securing code through proper authorization and access control. It recommends avoiding hard-coded authorization rules and instead using a centralized access control system. The document outlines some common anti-patterns like untrusted data driving access decisions and discusses how improper access controls can enable data tampering or disclosure of confidential information.
Security is important for Devs. You need to add in depth capability to secure Apps, and for this, this presentation give you simply principles to add it to a Java App.
This slides come from the Java User Group Summer Camp 2015 in France
Ce talk est une introduction au Secure Coding pour Java. Il s'efforcera de présenter via différents exemples les bonnes pratiques permettant de développer de manière pragmatique une application java sécurisée. Nous aborderons aussi bien des pratiques fonctionnelles que des morceaux de codes java à erreurs et leur correctifs.
Top Ten Proactive Web Security Controls v5Jim Manico
It is not easy to build a secure, low-risk or risk-managed web application. Firewalls, “policy” and other traditional information security measures serve as either an incomplete or useless measure in the pursuit of web application security.
As software developers author the code that makes up a web application, they need to do so in a secure manner. All tiers of a web application, the user interface, the business logic, the controller, the database code and more – all need to be developed with security in mind. This can be a very difficult task and developers are often set up for failure. Most developers did not learn about secure coding or crypto in school. The languages and frameworks that developers use to build web applications are often lacking critical core controls or are insecure by default in some way. There may be inherent flaws in requirements and designs. It is also very rare when organizations provide developers with prescriptive requirements that guide them down the path of secure software. When it comes to web security, developers are often set up to lose the security game.
This document was written by developers for developers, to assist those new to secure development. It aims to guide developers and other software development professionals down the path of secure web application software development.
This document is neither scientific nor complete. In fact it is a bit misguided. There are more than 10 issues that developers need to be aware of. Some of these “top ten” controls will be very specific, others will be general categories. Some of these items are technical, others are process based. Some may argue that this document includes items that are not even controls at all. All of these concerns are fair. Again, this is an awareness document meant for those new to secure software development. It is a start, not an end.
Problems With Parameters - A high-level overview of common vulnerabilities identified in web applications, techniques to mitigate these vulnerabilities, and thoughts on incorporating secure webapp development practices into your organization's development culture.
Security is important for Devs. You need to add in depth capability to secure Apps, and for this, this presentation give you simply principles to add it to a Java App.
This slides come from the Java User Group Summer Camp 2015 in France
Ce talk est une introduction au Secure Coding pour Java. Il s'efforcera de présenter via différents exemples les bonnes pratiques permettant de développer de manière pragmatique une application java sécurisée. Nous aborderons aussi bien des pratiques fonctionnelles que des morceaux de codes java à erreurs et leur correctifs.
Top Ten Proactive Web Security Controls v5Jim Manico
It is not easy to build a secure, low-risk or risk-managed web application. Firewalls, “policy” and other traditional information security measures serve as either an incomplete or useless measure in the pursuit of web application security.
As software developers author the code that makes up a web application, they need to do so in a secure manner. All tiers of a web application, the user interface, the business logic, the controller, the database code and more – all need to be developed with security in mind. This can be a very difficult task and developers are often set up for failure. Most developers did not learn about secure coding or crypto in school. The languages and frameworks that developers use to build web applications are often lacking critical core controls or are insecure by default in some way. There may be inherent flaws in requirements and designs. It is also very rare when organizations provide developers with prescriptive requirements that guide them down the path of secure software. When it comes to web security, developers are often set up to lose the security game.
This document was written by developers for developers, to assist those new to secure development. It aims to guide developers and other software development professionals down the path of secure web application software development.
This document is neither scientific nor complete. In fact it is a bit misguided. There are more than 10 issues that developers need to be aware of. Some of these “top ten” controls will be very specific, others will be general categories. Some of these items are technical, others are process based. Some may argue that this document includes items that are not even controls at all. All of these concerns are fair. Again, this is an awareness document meant for those new to secure software development. It is a start, not an end.
Problems With Parameters - A high-level overview of common vulnerabilities identified in web applications, techniques to mitigate these vulnerabilities, and thoughts on incorporating secure webapp development practices into your organization's development culture.
Hackers, meet your match. No longer are web applications an easy target. You have been getting away for too long with laughing at poor programming practices, pissing on every parameter,
and downloading entire tables from Web requests. In this talk, I will show a hands-on demo of a live application with a RASP, and without. I will cover the benefits of a RASP over a WAF, and explain
how web sites should no longer rely on dumb traffic level regex tools for their security.
I will attack a vulnerable web application, and demonstrate how a typical attack is carried out on it. Afterwards I will repeat the exercise on the same application, but this time with a RASP installed.
I will point out what the key differences are, and in a vendor neutral manner show key mechanisms which differentiate a RASP from a WAF or a firewall.
I will cover how brute force protection is done right, how aggregating application usage and sharing this data is beneficial, and how using a RASP can even be integrated into a SDLC.
Smart Sheriff, Dumb Idea, the wild west of government assisted parentingAbraham Aranguren
Would you want to let your kids discover the darker corners of the internet without protection? Wouldn't it be handy to know what they do online, to be alerted when they search for dangerous keywords and to be able to control what websites they can visit, and even when they play games?
Worry no longer, the South Korean government got you covered. Simply install the "Smart Sheriff" app on your and your kids' phones. Smart Sheriff is the first parental-control mobile app that has been made a legally required, obligatory install in an entire country! Yay, monitoring!
Well, something shady yet mandatory like this cannot go without an external pentest. And even better, one that wasn't solicited by the maintainer but initiated by the OTF and CitizenLab and executed by the Cure53 team! In this talk, two of the Cure53 testers involved into the first and, who would have guessed, second penetration test against the "Smart Sheriff" app, will share what they found. Maybe all was fine with the app, maybe the million kids forced to have this run on their devices were all safe. Maybe. But would there be a talk about it then?
We all know, mandated surveillance apps to protect children are a great idea, and outsourcing to the lowest bidder, always delivers the best results. Right?
Going over the first and second pentest results we will share our impressions about the "security" of this ecosystem and show examples about the "comprehensive" vendor response, addressing "all" the findings impeccably. This talk is a great example of how security research about a serious political decision and mandate might achieve nothing at all - or show, how a simple pentest together with excellent activist work can maybe spark a political discussion and more.
The Offensive Security Certified Professional (OSCP) is one of the most technical and most challenging certifications for information security professionals.
For More information please contact us : https://www.infosectrain.com/
Technology First
16th Annual Ohio Information Security Conference
OISC 2019
#OISC19
The OWASP Top 10 & AppSec Primer
By Matt Scheurer (@c3rkah)
Dayton, Ohio
Date: 03/13/2019
Abstract:
Are you testing the security of your web applications, web sites, and web servers? The malicious threat actors on the Internet almost certainly are. We will cover AppSec along with a brief review of the 2017 OWASP Top 10 List. The focus of the presentation is how to get started with AppSec and where to continue learning more. Accompanying the presentation are live demos of Nikto and the OWASP Zed Attack Proxy (ZAP).
Bio:
Matt Scheurer serves as Chair of the Cincinnati Networking Professionals Association Security Special Interest Group (CiNPA Security SIG) and works as a Systems Security Engineer in the Financial Services industry. He holds a CompTIA Security+ Certification and possesses multiple Microsoft Certifications including MCP, MCPS, MCTS, MCSA, and MCITP. He has presented on numerous Information Security topics as a featured speaker at many local area technology groups and large Information Security conferences all over the Ohio, Indiana, and Kentucky Tri-State. Matt maintains active memberships in a number of professional organizations including the Association for Computing Machinery (ACM), Cincinnati Networking Professionals Association (CiNPA), Financial Services - Information Sharing and Analysis Center (FS-ISAC), and Information Systems Security Association (ISSA).
Technical Architecture of RASP TechnologyPriyanka Aash
APPSEC CHALLENGES
- Writing Secure Code is not Easy
- Most follows agile development strategies
- Frequent releases and builds
- Any release can introduce or reintroduce vulnerabilities
- Problems by design.
Ex: Session Hijacking, Credential Stuffing
Modern development teams are delivering features at a rapid pace using modern technologies such as containers, microservices, and serverless functions. Operations and infrastructure teams are supporting these rapid delivery cycles using Infrastructure as Code, Test Driven Infrastructure (TDI), and cloud automation. Yet, most security teams are still using traditional security approaches and can't keep up with the rate of accelerated change.
Security must be reinvented in a DevOps world to take advantage of the opportunities provided by continuous integration and delivery pipelines. In this talk, attendees will take a journey through the DevSecOps Toolchain broken down into the key phases: pre-commit, commit, acceptance, production, and operations. We will explore the pre-commit and commit phases in-depth, identifying security controls, open source tools, and how to integrate these tools into a pipeline. Attendees will walk away with a practical approach for weaponizing the toolchain and building a successful DevSecOps program.
Hackers, meet your match. No longer are web applications an easy target. You have been getting away for too long with laughing at poor programming practices, pissing on every parameter,
and downloading entire tables from Web requests. In this talk, I will show a hands-on demo of a live application with a RASP, and without. I will cover the benefits of a RASP over a WAF, and explain
how web sites should no longer rely on dumb traffic level regex tools for their security.
I will attack a vulnerable web application, and demonstrate how a typical attack is carried out on it. Afterwards I will repeat the exercise on the same application, but this time with a RASP installed.
I will point out what the key differences are, and in a vendor neutral manner show key mechanisms which differentiate a RASP from a WAF or a firewall.
I will cover how brute force protection is done right, how aggregating application usage and sharing this data is beneficial, and how using a RASP can even be integrated into a SDLC.
Smart Sheriff, Dumb Idea, the wild west of government assisted parentingAbraham Aranguren
Would you want to let your kids discover the darker corners of the internet without protection? Wouldn't it be handy to know what they do online, to be alerted when they search for dangerous keywords and to be able to control what websites they can visit, and even when they play games?
Worry no longer, the South Korean government got you covered. Simply install the "Smart Sheriff" app on your and your kids' phones. Smart Sheriff is the first parental-control mobile app that has been made a legally required, obligatory install in an entire country! Yay, monitoring!
Well, something shady yet mandatory like this cannot go without an external pentest. And even better, one that wasn't solicited by the maintainer but initiated by the OTF and CitizenLab and executed by the Cure53 team! In this talk, two of the Cure53 testers involved into the first and, who would have guessed, second penetration test against the "Smart Sheriff" app, will share what they found. Maybe all was fine with the app, maybe the million kids forced to have this run on their devices were all safe. Maybe. But would there be a talk about it then?
We all know, mandated surveillance apps to protect children are a great idea, and outsourcing to the lowest bidder, always delivers the best results. Right?
Going over the first and second pentest results we will share our impressions about the "security" of this ecosystem and show examples about the "comprehensive" vendor response, addressing "all" the findings impeccably. This talk is a great example of how security research about a serious political decision and mandate might achieve nothing at all - or show, how a simple pentest together with excellent activist work can maybe spark a political discussion and more.
The Offensive Security Certified Professional (OSCP) is one of the most technical and most challenging certifications for information security professionals.
For More information please contact us : https://www.infosectrain.com/
Technology First
16th Annual Ohio Information Security Conference
OISC 2019
#OISC19
The OWASP Top 10 & AppSec Primer
By Matt Scheurer (@c3rkah)
Dayton, Ohio
Date: 03/13/2019
Abstract:
Are you testing the security of your web applications, web sites, and web servers? The malicious threat actors on the Internet almost certainly are. We will cover AppSec along with a brief review of the 2017 OWASP Top 10 List. The focus of the presentation is how to get started with AppSec and where to continue learning more. Accompanying the presentation are live demos of Nikto and the OWASP Zed Attack Proxy (ZAP).
Bio:
Matt Scheurer serves as Chair of the Cincinnati Networking Professionals Association Security Special Interest Group (CiNPA Security SIG) and works as a Systems Security Engineer in the Financial Services industry. He holds a CompTIA Security+ Certification and possesses multiple Microsoft Certifications including MCP, MCPS, MCTS, MCSA, and MCITP. He has presented on numerous Information Security topics as a featured speaker at many local area technology groups and large Information Security conferences all over the Ohio, Indiana, and Kentucky Tri-State. Matt maintains active memberships in a number of professional organizations including the Association for Computing Machinery (ACM), Cincinnati Networking Professionals Association (CiNPA), Financial Services - Information Sharing and Analysis Center (FS-ISAC), and Information Systems Security Association (ISSA).
Technical Architecture of RASP TechnologyPriyanka Aash
APPSEC CHALLENGES
- Writing Secure Code is not Easy
- Most follows agile development strategies
- Frequent releases and builds
- Any release can introduce or reintroduce vulnerabilities
- Problems by design.
Ex: Session Hijacking, Credential Stuffing
Modern development teams are delivering features at a rapid pace using modern technologies such as containers, microservices, and serverless functions. Operations and infrastructure teams are supporting these rapid delivery cycles using Infrastructure as Code, Test Driven Infrastructure (TDI), and cloud automation. Yet, most security teams are still using traditional security approaches and can't keep up with the rate of accelerated change.
Security must be reinvented in a DevOps world to take advantage of the opportunities provided by continuous integration and delivery pipelines. In this talk, attendees will take a journey through the DevSecOps Toolchain broken down into the key phases: pre-commit, commit, acceptance, production, and operations. We will explore the pre-commit and commit phases in-depth, identifying security controls, open source tools, and how to integrate these tools into a pipeline. Attendees will walk away with a practical approach for weaponizing the toolchain and building a successful DevSecOps program.
Platform Security IRL: Busting Buzzwords & Building BetterEqual Experts
Practical tips and heroic war stories on how to secure a large, modern, fast software delivery platform. From building a team to building cool stuff, dealing with organisational setups to dealing with security incidents.
Zero Buzzwords Guaranteed.
Chris Rutter has spent the last few years obsessed with making security, engineering and the business work together. Starting his career as an engineer, he uses a deep understanding of Agile, Devops, and product delivery to solve security problems in a way that enables teams, rather than hitting them with bricks.
OWASP Security Logging API easily extends your current log4j and logback logging with impressive features helpful for security, diagnostics/forensics, and compliance. Slide deck presentation from OWASP AppSecEU 2016 in Rome.
This presentation talks about the focus towards building security in the software development life cycle and covers details related to Reconnaissance, Scanning and Attack based test design and execution approach.
Bringing Security Testing to Development: How to Enable Developers to Act as ...Achim D. Brucker
Security testing is an important part of any security development life-cycle (SDLC) and, thus, should be a part of any software development life-cycle.
We will present SAP's Security Testing Strategy that enables developers to find security vulnerabilities early by applying a variety of different security testing methods and tools. We explain the motivation behind it, how we enable global development teams to implement the strategy, across different SDLCs and report on our experiences.
Martin Toshev - Java Security Architecture - Codemotion Rome 2019Codemotion
The session provides an overview of the security architecture of the Java platform in terms of its evolution throughout the versions of the JDK up to JDK 11 and beyond. The security utilities that fullfill the security portfolio of the JDK will be discussed briefly along with several guidelines in designing and implementing secure applications by following security best practices.
Drupal, WordPress, and Joomla are very popular Content Management Systems (CMS) that have been widely adopted by government agencies, major businesses, social networks, and more — underscoring why understanding how these systems work and properly securing these applications is of the utmost importance. This talk focuses on the penetration tester’s perspective of CMS’ and dives into streamlining the assessment and remediation of commonly observed application and configuration flaws by way of custom exploit code and security checklists- all of which are open-source and can be downloaded and implemented following the presentation.
Ce talk est une introduction au Secure Coding pour Java. Il s'efforcera de présenter via différents exemples les bonnes pratiques permettant de développer de manière pragmatique une application java sécurisée. Nous aborderons aussi bien des pratiques fonctionnelles que des morceaux de codes java à erreurs et leur correctifs
This 7-second Brain Wave Ritual Attracts Money To You.!nirahealhty
Discover the power of a simple 7-second brain wave ritual that can attract wealth and abundance into your life. By tapping into specific brain frequencies, this technique helps you manifest financial success effortlessly. Ready to transform your financial future? Try this powerful ritual and start attracting money today!
1.Wireless Communication System_Wireless communication is a broad term that i...JeyaPerumal1
Wireless communication involves the transmission of information over a distance without the help of wires, cables or any other forms of electrical conductors.
Wireless communication is a broad term that incorporates all procedures and forms of connecting and communicating between two or more devices using a wireless signal through wireless communication technologies and devices.
Features of Wireless Communication
The evolution of wireless technology has brought many advancements with its effective features.
The transmitted distance can be anywhere between a few meters (for example, a television's remote control) and thousands of kilometers (for example, radio communication).
Wireless communication can be used for cellular telephony, wireless access to the internet, wireless home networking, and so on.
Multi-cluster Kubernetes Networking- Patterns, Projects and GuidelinesSanjeev Rampal
Talk presented at Kubernetes Community Day, New York, May 2024.
Technical summary of Multi-Cluster Kubernetes Networking architectures with focus on 4 key topics.
1) Key patterns for Multi-cluster architectures
2) Architectural comparison of several OSS/ CNCF projects to address these patterns
3) Evolution trends for the APIs of these projects
4) Some design recommendations & guidelines for adopting/ deploying these solutions.
ER(Entity Relationship) Diagram for online shopping - TAEHimani415946
https://bit.ly/3KACoyV
The ER diagram for the project is the foundation for the building of the database of the project. The properties, datatypes, and attributes are defined by the ER diagram.
1. 42
minutes
to
secure
your
code….
Sébastien Gioria
sebastien.gioria@owasp.org
OWASP
France
Leader
&
Evangelist
JUG
Summer
Camp
18
Septembre 2015
LaRochelle -‐ France
3. 2
http://www.google.fr/#q=sebastien
gioria
‣OWASP France Leader & Founder &
Evangelist,
‣OWASP ISO Project & OWASP SonarQube Project
Leader
‣Innovation and Technology @Advens &&
Application Security Expert
Twitter :@SPoint/@OWASP_France/@AppSecAcademy2
‣Application Security group leader for the
CLUSIF
‣Proud father of youngs kids trying to hack my
digital life.
‣Legal expert for Cour of Appeal of Poitiers
5. OWASP
publications
!
• Publications
:
– Top10
Application
Security
Risk
;
bestseller
– Testing
Guide
;
second
bestseller
– OWASP
Cheat
Sheets
!!!
– Application
Security
Verification
Standard
;
not
the
best
well
known
document
– OpenSAMM :
improve
your
application
security
– OWASP
Secure
Contract
Annex
– OWASP
Top10
for
...
(mobile,
cloud,
privacy,
...)
• Tools
/
API
– OWASP
Zed
Attack
Proxy
;
replace
WebScarab with
a
lot
of
new
functionalities
– OWASP
ESAPI
:
API
for
securing
your
Software
– OWASP
AppSensor ;
a
IDS/IPS
in
the
heart
of
your
software
– OWASP
Cornucoppia ;
application
security
play
with
cards
– OWASP
Snake
and
ladder
:
play
Top10
and
many
more....
19. Moral
!
NEVER re-implements
security mechanisms that are
approuved in a core library !!
This
is
the
same
thing
for
crypto
and
other
mechanisms
that
are
not
security....
20. public final class InsertEmployeeActionextends Action{
public ActionForward execute(ActionMappingmapping,ActionForm form,
HttpServletRequest request,HttpServletResponseresponse)throws Exception{
Obj1 service= new Obj1();
ObjForm objForm = (ObjForm) form;
InfoADT adt = new InfoADT();
BeanUtils.copyProperties(adt,objForm);
String searchQuery= objForm.getqueryString();
String payload = objForm.getPayLoad();
try {
service.doWork(adt); / /do somethingwith thedata
ActionMessages messages = new ActionMessages();
ActionMessagemessage= new ActionMessage("success",adt.getName());
messages.add(ActionMessages.GLOBAL_MESSAGE,message);
saveMessages(request, messages );
request.setAttribute("Record",adt);
return (mapping.findForward("success"));
}
catch( DatabaseExceptionde)
{
ActionErrors errors = new ActionErrors();
ActionError error = new ActionError("error.employee.databaseException" + “Payload:“+payload);
errors.add(ActionErrors.GLOBAL_ERROR,error );
saveErrors(request,errors );
return (mapping.findForward("error: "+ searchQuery));
}
}
}
Spot
the
vuln(s)
!
21. XSS
risks
• Session Hijacking
• Site Defacement
• Network Scanning
• Undermining CSRF Defenses
• Site Redirection/Phishing
• Load of Remotely Hosted Scripts
• Data Theft
• Keystroke Logging
• Attackers using XSS more frequently
24. Encoding
Output
Characters Decimal Hexadecimal
HTML
Character
Set
Unicode
"
(double
quotation
marks)
" " " u0022
'
(single
quotation
mark)
' ' ' u0027
&
(ampersand) & & & u0026
<
(less
than) < < < u003c
>
(greater
than) > > > u003e
Safe
ways
to
represent
dangerous
characters
in
a
web
page
25. OWASP Java Encoder Project
https://www.owasp.org/index.php/OWASP_Java_Encoder_Project
• No third party libraries or configuration necessary
• This code was designed for high-availability/high-
performance encoding functionality
• Simple drop-in encoding functionality
• Redesigned for performance
• More complete API (uri and uri component encoding,
etc) in some regards.
• Java 1.5+
28. OWASP HTML Sanitizer Project
https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project
• HTML Sanitizer written in Java which lets you include HTML
authored by third-parties in your web application while protecting
against XSS.
• This code was written with security best practices in mind, has an
extensive test suite, and has undergone adversarial security review
https://code.google.com/p/owasp-java-html-
sanitizer/wiki/AttackReviewGroundRules.
• It allows for simple programmatic POSITIVE policy configuration.
No XML config.
• Actively maintained by Mike Samuel from Google's AppSec team!
• This is code from the Caja project that was donated by Google. It
is rather high performance and low memory utilization.
29. • Upload Verification
– Filename and Size validation + antivirus
• Upload Storage
– Use only trusted filenames + separate domain
• Beware of "special" files
– "crossdomain.xml" or "clientaccesspolicy.xml".
• Image Upload Verification
– Enforce proper image size limits
– Use image rewriting libraries
– Set the extension of the stored image to be a valid image extension
– Ensure the detected content type of the image is safe
• Generic Upload Verification
– Ensure decompressed size of file < maximum size
– Ensure that an uploaded archive matches the type expected (zip, rar)
– Ensure structured uploads such as an add-on follow proper standard
30.
31. What
is
Access
Control?
• Authorization is the process where a system determines
if a specific user has access to a resource
• Permission: Represents app behavior only
• Entitlement: What a user is actually allowed to do
• Principle/User: Who/what you are entitling
• Implicit Role: Named permission, user associated
– if (user.isRole(“Manager”));;
• Explicit Role: Named permission, resource associated
– if (user.isAuthorized(“report:view:3324”);;
32. Access Control Anti-Patterns
• Hard-coded role checks in application code
• Lack of centralized access control logic
• Untrusted data driving access control decisions
• Access control that is “open by default”
• Lack of addressing horizontal access control in a
standardized way (if at all)
• Access control logic that needs to be manually
added to every endpoint in code
• Access Control that is “sticky” per session
• Access Control that requires per-user policy
33. Access
Controls
Impact
• Loss
of
accountability
– Attackers
maliciously
execute
actions
as
other
users
– Attackers
maliciously
execute
higher
level
actions
• Disclosure
of
confidential
data
– Compromising
admin-‐level
accounts
often
results
in
access
to
user’s
confidential
data
• Data
tampering
– Privilege
levels
do
not
distinguish
users
who
can
only
view
data
and
users
permitted
to
modify
data
34. void editProfile(User u, EditUser eu) {
if (u.isManager()) {
editUser(eu)
}
}
HardCode Auth Rule
35. void editProfile(User u, EditUser eu) {
if ((user.isManager() ||
user.isAdministrator() ||
user.isEditor()) &&
user.id() != 1132))
{
// do stuff
}
}
Policy
evolution....
37. Hard-‐Coded
Roles
• Makes
“proving”
the
policy
of
an
application
difficult
for
audit
or
Q/A
purposes
• Any
time
access
control
policy
needs
to
change,
new
code
need
to
be
pushed
• RBAC(http://en.wikipedia.org/wiki/Role-‐
based_access_control)
is
often
not
granular
enough
• Fragile,
easy
to
make
mistakes
38. Never
Depend
on
Untrusted
Data
• Never
trust
request
data
for
access
control
decisions
• Never
make
access
control
decisions
in
JavaScript
• Never
make
authorization
decisions
based
solely
on:
hidden
fields
cookie
values
form
parameters
URL
parameters
anything
else
from
the
request
• Never
depend
on
the
order
of
values
sent
from
the
client
39. Best
Practice:
Centralized
AuthZ
• Define
a
centralized
access
controller
– ACLService.isAuthorized(PERMISSION_CONSTANT)
– ACLService.assertAuthorized(PERMISSION_CONSTANT)
• Access
control
decisions
go
through
these
simple
API’s
• Centralized
logic
to
drive
policy
behavior
and
persistence
• May
contain
data-‐driven
access
control
policy
information
40. int userId= request.getInt(”userID"); //Best to get it from sessionID....
if (validateUser(userId) ) {
if ( currentUser.isPermitted( ”module:function:" + userId) ) {
log.info(userId + “are permitted to access .");
doStuff(userId);
} else {
log.info(userId + “ is notallowed to access!");
throw new AuthorizationException (userId);
}
}
Should
be
like
this...
42. 1) Do
not
limit
the
type
of
characters
or
length
of
user
password
within
reason
• Be
wary
of
systems
that
allow
unlimited
password
sizes
(Django DOS
Sept
2013)
• 2)
Use
a
cryptographically
strong
credential-‐specific
salt
• 3)
Impose
difficult
verification
• on
the
attacker
and
defender
:
use
PBKDF2
or
script
• on
only the
attacker
:
use
HMAC-‐SHA-‐256
43. 2)
Use
a
cryptographically
strong
credential-‐
specific
salt
• protect(
[salt]
+
[password]
);
• Use
a
32char
or
64char
salt
(actual
size
dependent
on
protection
function);
• Do
not
depend
on
hiding,
splitting,
or
otherwise
obscuring
the
salt
44. 3a)
Impose
difficult
verification
on
the
attacker
and
defender
•PBKDF2([salt]
+
[password],
c=140,000);
•Use
PBKDF2 when
FIPS
certification
or
enterprise
support
on
many
platforms
is
required
•Use
Scrypt where
resisting
any/all
hardware
accelerated
attacks
is
necessary
but
enterprise
support
and
scale
is
not.
(bcrypt is
also
a
reasonable
choice)
45. 3b)
Impose
difficult
verification
on
only the
attacker
•HMAC-‐SHA-‐256(
[private
key],
[salt]
+
[password]
)
•Protect
this
key
as
any
private
key
using
best
practices
•Store
the
key
outside
the
credential
store
•Build
the
password-‐to-‐hash
conversion
as
a
separate
webservice (cryptograpic isolation).
47. Require
2
identity
questions
<Last
name,
account
number,
email,
DOB
<Enforce
lockout
policy
Ask
one
or
more
good
security
questions
<https://www.owasp.org/index.php/Choosing_and_Using_Security_
Questions_Cheat_Sheet
Send
the
user
a
randomly
generated
token
via
out-‐of-‐band
<app,
SMS
or
token
Verify
code
in
same
web
session
<Enforce
lockout
policy
Change
password
<Enforce password policy
Changing
Password
48. //import
java.security and
java.crypto and
java.util needed
//
Based on
recommendation from NIST
SP800-‐132.pdf
public
class
PasswordEncryptionService {
public
boolean authenticate(String
attemptedPassword,
byte[]
encryptedPassword,
byte[]
salt)
throws NoSuchAlgorithmException,
InvalidKeySpecException {
byte[]
encryptedAttemptedPassword =
getEncryptedPassword(attemptedPassword,
salt);
return
Arrays.equals(encryptedPassword,
encryptedAttemptedPassword);
}
public
byte[]
getEncryptedPassword(String
password,
byte[]
salt)
throws NoSuchAlgorithmException,
InvalidKeySpecException {
String
algorithm =
"PBKDF2WithHmacSHA1’’;
//
SHA1
recommende by
nist
int derivedKeyLength =
160;
int iterations =
20000;
//
minimum
1000
its from NIST
KeySpec spec =
new
PBEKeySpec(password.toCharArray(),
salt,
iterations,
derivedKeyLength);
SecretKeyFactory f
=
SecretKeyFactory.getInstance(algorithm);
return
f.generateSecret(spec).getEncoded();
}
public
byte[]
generateSalt()
throws NoSuchAlgorithmException {
SecureRandom random =
SecureRandom.getInstance("SHA1PRNG");
byte[]
salt =
new
byte[8];
random.nextBytes(salt);
return
salt;
SecurePasswordStorage
51. • What benefits do HTTPS provide?
– Confidentiality, Integrity and Authenticity
– Confidentiality: Spy cannot view your data
– Integrity: Spy cannot change your data
– Authenticity: Server you are visiting is the
right one
52. Encryption in Transit (HTTPS/TLS)
• HTTPS configuration best practices
– https://www.owasp.org/index.php/Transport_L
ayer_Protection_Cheat_Sheet
– https://www.ssllabs.com/projects/best-
practices/
54. HSTS
– Strict
Transport
Security
• HSTS
(Strict
Transport
Security)
– http://www.youtube.com/watch?v=zEV3HOuM_Vw
– Strict-‐Transport-‐Security:
max-‐age=31536000;
includeSubdomains
• Forces
browser
to
only
make
HTTPS
connection
to
server
• Must
be
initially
delivered
over
a
HTTPS
connection
57. Risks
?
• Error messages
can disclose information
valuable to
an
attacker
• Failure can lead
to
an
unhandled state,
which
can lead
to
denial of
service
– Unhandled
failures can lead
to
malicious behavior being
unnoticed
58. Fail
Securely
!
• Not
Just
catching
exception
• Not
Just
logging
exception/errors
Handle
all
failures
securely
and
return
the
system
to
a
proper
state
59. Design
Patterns
• Don't assume
that an
error condition
won't occur
• It's what the
attackers want you to
assume
• Errors are
like accidents,
you don't expect them,
but
they
happen
• Any code
that can throw an
exception
should be in
a
Try
Block
• Handle all
possible
exceptions
• Use
Finally Blocks:
leaving files
open
or
exceptions
defined
after use
creates resource leaks and
possible
system
failure
• Short
specific Try Blocks
give you more
control
over
the
error state
60. App
Layer
Intrusion
Detection
• Great detection points to start with
– Input validation failure server side when client side
validation exists
– Input validation failure server side on non-user
editable parameters such as hidden fields,
checkboxes, radio buttons or select lists
– Forced browsing to common attack entry points
– Honeypot URL (e.g. a fake path listed in robots.txt
like e.g. /admin/secretlogin.jsp)
61. App
Layer
Intrusion
Detection
• Others
– Blatant SQLi or XSS injection attacks
– Workflow sequence abuse (e.g. multi-part form in
wrong order)
– Custom business logic (e.g. basket vs catalogue
price mismatch)
– Further Study:
• “libinjection: from SQLi to XSS” – Nick Galbreath
• “Attack Driven Defense” – Zane Lackey
62. OWASP AppSensor (Java)
• Project and mailing list
https://www.owasp.org/index.php/OWASP_A
ppSensor_Project
• Four-page briefing, Crosstalk, Journal of
Defense Software Engineering
• http://www.crosstalkonline.org/storage/issue-
archives/2011/201109/201109-Watson.pdf
66. Security Architecture and Design
Strategic
effort
• Business,
technical
and
security
stakeholders
• Functional
and
non-‐functional
security
properties
• Different
flavors/efforts
based
on
SDL/culture
Example:
state
• Should
you
use
the
request?
• Should
you
use
a
web
session?
• Should
you
use
the
database?
These
decisions
have
dramatic
security
implications
67. Trusting Input
• Treating all client side data as untrusted is
important, and can be tied back to trust
zones/boundaries in design/architecture.
• Ideally we want to consider all tiers to be
untrusted and build controls at all layers,
but this is not practical or even possible for
some very large systems.
68. Security Architecture and Design
Additional
Considerations
• Overall
Architecture/Design
• Trust
Zones/Boundaries/Tiers
1. User
Interface,
API
(Webservices),
2. Business
Layer
(Custom
Logic),
3. Data
Layer
(Keys
to
the
Kingdom)
4. What
sources
can/cannot
be
trusted?
• What
is
inside/outside
of
a
trust
zone/boundary
• Specific
controls
need
to
exist
at
certain
layers
• Attack
Surface
77. Good
Try...but...catch
J
public
class
BadCatch {
public
void mymethodErr1()
{
try {
//do
Stuff
}
catch
(SecurityException se){
System.err.println (se);
}
}
}
78. Nice
comments
//
Pattern
to
match
the
string
Pattern
myPattern =
"bword1W+(?:w+/W+){1,6}?word2b";
String
updated =
MYCONSTANT1.replaceAll(mypattern,
"$2");
//
i
iterate from 0
to
10
for
(int i=0;
i
<10
;
i++)
{
//
do
stuff
myMethod(updated);
}
79. Unit
testing
• In
computer
programming,
unit
testing is a
software
testing method by
which
individual units of
source
code,
sets
of
one
or
more
computer
program
modules
together with associated control
data,
usage
procedures,
and
operating
procedures,
are
tested to
determine whether they are
fit
for
use..
(c)
Wikipedia