Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Application Security

No description
by

Nir Valtman

on 9 November 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Application Security

Nir Valtman
Application Security
General principles
OWASP TOP 10

Agenda
Secure development - why now?
When?
Digital age - every moment information is being processed.
Why?
Handling information by applications.
How?
The most critical part is to secure the application while designing (preferred) or developing.
Execution?
It is possible to develop full functional application in a secure manner.
The initiation level should include risk assessment by security architect.

The design level should include the detailed application security requirements.

The testing level should include scripts, which should verify that the secure development requirements.

CISO\CSO should approve or decline the upgrade to production environment or product release.

These principles are applicable to each application. It is not important which development language, platform or hardware.

Writing a secure application is not enough. It should be maintained by SDL.
General principles
Source: microsoft.com
Simplified SDL process
Source: microsoft.com
SDL and agile methodologies
Threat modeling
While designing the application, the threats should be identified.

On each logic process in applications there are weaknesses. It is possible to minimize the risks.

There are various threat modeling modules:
Microsoft threat modeling process
Trike threat modeling framework
AS/NZS 4360 (Australia/New Zealand)
Common Vulnerability Scoring System
(CVSS) - US department
Octave
Threat modeling - STRIDE
Countermeasures
Use strong authentication.
Do not store secrets in plaintext.
Do not use credentials in plaintext over the wire.
Protect authentication cookies with Secure Socket Layer (SSL).
Threat: Spoofing user identity
Countermeasures
Use data hashing and signing.
Use digital signatures.
Use strong authorization.
Use tamper-resistant protocols across communication links.
Secure communication links with protocols that provide message integrity.
Threat: Tampering with data
Countermeasures
Create secure audit trails.
Use digital signatures.
Threat: Repudiation
Countermeasures
Use strong authorization.
Use string encryption.
Secure communication links with protocols that provide message confidentiality.
Do not store secrets in plaintext.
Threat: Information Disclosure
Countermeasures
Use resource and bandwidth throttling techniques.
Validate and filter input.
Threat: Denial of service
Countermeasure
Follow the principle of least privilege to use least privileged service accounts to run processes and access resources.
Threat: Elevation of privilege
Source: microsoft.com
Threat model - DREAD
General guidelines
Permissions based on least privilege method

Better parameters security
protected
private

As a result, even though attacker gets access to the application, he can not get full access.

Important: All information may be accessed on Reflection, Serialization and Debugging processes.
Mandatory access
Each platform holds access control list, whether for processes or file system.

Each application should have its user on the operating system. The user would be restricted to minimum permissions.

It is important to avoid anonymous access to view directory structures.
ACL for processes
Sensitive information should be stored in a secure manner.

What does the strength of the encryption key mean?

Hence, asymmetric 512bit encryption is hard to brake, even though it considered as breakable.

The best known symmetric algorithms are AES and TEA.

Password should be hashed (SHA1, SHA-256)
Encryption
Audit/Alert/Block the following events:
Log on (if possible).
Multiple logons to specific account.
Multiple logons to multiple accounts from specific IP address.
Note: NAT might me an issue.

Infrastructure audit:
Service logs (e.g. IIS).
Server logs (e.g. Windows).
Network logs (e.g. IPS, FW).
Audit & Alert
Each application has set of states that provides access for a certain user in the application.

The user might be represented by:
String
Integer
Boolean (e.g. isAdmin)

The most common vulnerability is substitution of the user identification.
State management
I wouldn't believe it either :-)
User's information should include:
Encryption.
UUID (e.g. TokenID).
Timeout
It is possible to kill connection while trying to execute parameter manipulations.
State management
Code should be written as flow independent.

Each component should be handled separately since sometimes it is possible to call them in a different way (bypassing functions).

Avoid using user inputs when calling ASSERT functions.

All functions should be tested by using automatic scanning tools and fuzzers, which may assist with producing the non-discoverable scripts.
Independent code
A.K.A Role Based Access Control.

The safest method for implementing authorization is RBAC.

By assigning authorization access to individual users, there is high possibility that someone will get wrong.
RBAC
A claim is a statement that one subject makes about itself or another object.

The statement can be about a name, identity, key, group, privilege or capability.

Claim based services provided with:
NTLM
Kerberos
PKI
SAML
Claim based identity & access control
Do not store sensitive information in the cache of the browser.

Use "No-Store" in the cache-control.

Note: No-Cache might save information on different browsers (e.g Firefox)
Cache
Autocomplete
Autocomplete="off" inside input tags.

Autofill
Browser based (i.e. Firefox, Chrome).
Could lead to click jacking.
Auto[anything]
Attacker might flood client/server/both

Source locations
"Contact us"
Source code
whois

Protection mechanisms
CAPTCHA
TokenID
Flooding
X-Frame-Options
Tells the browser whether or not to allow web page to be framed in another web page.
Configuration: DENY or SAMEORIGIN

X-XSS-Protection
Use an XSS filter, which is built in IE 8+.
Configuration: X-XSS-Protection "1; mode=block"

There is more to explore, e.g. X-Content-Security-Policy etc.
Use preventive HTTP headers
We have FW and it has statefull inspection.

Our web site is protected by SSL.

It's not a bug, it's a feature.

The servers are hardened and patched.

All servers has anti virus/malware.

Our IPS prevents malicious attacks i.e. DoS.
Application security myths
A1: Injection
A2: Cross Site Scripting (XSS)
A3: Broken Authentication and Session Management
A4: Insecure Direct Object References
A5: Cross Site Request Forgery (CSRF)
A6: Security Misconfiguration
A7: Failure to Restrict URL Access
A8: Unvalidated Redirects and Forwards
A9: Insecure Cryptographic Storage
A10: Insufficient Transport Layer Protection
OWASP TOP 10
DEMO
Do you think that application security is expensive? Try to ignore it!
Questions?
Full transcript