- Software Security
- Language-Based Security
- Application Level Security
- Github Repository
- Software security entails software that continues to function correctly under malicious attack.
- Most engineers acknowledge that security is important but don’t know the steps to tackle security
- Software security best practices leverage good software engineering practice
- Involve thinking about security early in the software lifecycle, knowing and understanding common threats
- Including language-based flaws and pitfalls
- designing for security
- Putting all software components thorough objective risk analyses and testing.
Difference between Software Security and Application Security
Gary McGraw maintains that application security is a reactive approach, taking place once software has been deployed. Software security, on the other hand, involves a proactive approach, taking place within the pre-deployment phase.
Software security (pre-deployment) activities include:
- Secure software design
- Development of secure coding guidelines for developers to follow
- Development of secure configuration procedures and standards for the deployment phase
- Secure coding that follows established guidelines
- Validation of user input and implementation of a suitable encoding strategy
- User authentication
- User session management
- Function level access control
- Use of strong cryptography to secure data at rest and in transit
- Validation of third-party components
- Arrest of any flaws in software design/architecture
Application security (post-deployment) activities include:
- Post deployment security tests
- Capture of flaws in software environment configuration
- Malicious code detection (implemented by the developer to create backdoor, time bomb)
- Meaning that situations like third party software or dependencies needing to be patched
- IP filtering
- White List Known Good IP addresses instead of leaving a bunch IP addresses open
- Lock down executables
- This in my mind goes more hand in hand with compiled languages but I could be wrong
- Monitoring of programs at runtime to enforce the software use policy
Language-based security (LBS) is a set of techniques that may be used to strengthen the security of applications on a high level by using the properties of programming languages. LBS is considered to enforce computer security on an application-level, making it possible to prevent vulnerabilities which traditional operating system security is unable to handle.
Objectives of Language Based Security
Objective of Language-based security:
- Prevent common programming errors such as allowing buffer overflows and illegal information flows to occur
Provide some proof to the consumer about the security properties of the software
- Helps the consumer trust the software without having to check source code for errors.
A compiler, taking source code as input, performs several language specific operations on the code
- Lexical analysis, preprocessing, parsing, semantic analysis, code generation, and code optimization
- By analyzing the source code and gathering best practices for the language
- The compiler will attempt to correctly translate the high-level code into low-level code
- Preserving the behavior of the program.
For Dynamic Libraries such as Javasript/Node.js you can use tools such as eslint that help with static analysis and best practices that you should follow
Application Level Security
- Encompasses measures taken to improve the security of an application
- By finding, fixing and preventing security vulnerabilities.
- Data in a database, money in an account, file on the filesystem or any system resource.
- A gap in security program that can be exploited by threats to gain unauthorized access to an asset.
- An action taken to harm an asset.
- Anything that can exploit a vulnerability and obtain, damage, or destroy an asset.
- Code review
- Security engineer who understands the application through manually reviewing the source code notices avenues of exploit.
- Blackbox security audit
- This is testing an application for security vulnerabilities not looking at source code
- Design review
- Thinking about possible threat models before writing code or using a spec that has it detailed.
- Automated tools that check security vulnerabilities
Application threats or attacks
|Input Validation||Buffer overflow; cross-site scripting; SQL injection; canonicalization|
|Software Tampering||Attacker modifies an existing application’s runtime behavior to perform unauthorized actions; exploited via binary patching, code substitution, or code extension|
|Authentication||Network eavesdropping ; Brute force attack; dictionary attacks; cookie replay; credential theft|
|Authorization||Elevation of privilege; disclosure of confidential data; data tampering; luring attacks|
|Configuration management||Unauthorized access to administration interfaces; unauthorized access to configuration stores; retrieval of clear text configuration data; lack of individual accountability; over-privileged process and service accounts|
|Sensitive information||Access sensitive code or data in storage; network eavesdropping; code/data tampering|
|Session management||Session hijacking; session replay; man in the middle|
|Cryptography||Poor key generation or key management; weak or custom encryption|
|Parameter manipulation||Query string manipulation; form field manipulation; cookie manipulation; HTTP header manipulation|
|Exception management||Information disclosure; denial of service|
|Auditing and logging||User denies performing an operation; attacker exploits an application without trace; attacker covers his or her tracks|
The Open Web Application Security Project (OWASP)
Background on OWASP
- Mission is to make software security visible, so that individuals/organizations can make informed decisions.
- Operates as a community of security minded professionals
- OWASP issues software tools and knowledge-based documentation on application security.
- The OWASP Foundation came online on December 1st 2001 it was established as a not-for-profit charitable org
- In the United States on April 21, 2004 to ensure the ongoing availability and support for our work at OWASP.
- OWASP is an international organization and the OWASP Foundation supports OWASP efforts around the world.
OWASP Core Values
- OPEN Everything at OWASP is radically transparent from our finances to our code.
- INNOVATION OWASP encourages and supports innovation and experiments for solutions to software security challenges.
- GLOBAL Anyone around the world is encouraged to participate in the OWASP community.
- INTEGRITY OWASP is an honest and truthful, vendor neutral, global community.
- Free & Open
- Governed by rough consensus & running code
- Abide by a code of ethics (see ethics)
- Not driven by commercial interests
- Risk based approach
OWASP Mailing Lists
OWASP Github Organization
OWASP Member Portal
OWASP Top 10
We will be reviewing the OWASP top 10 list for this workshop
OWASP Top 10 Most Critical Web Application Security Risks (in the Release Candidate) are: * Injection * Broken Authentication and Session Management * Cross-Site Scripting (XSS) * Broken Access Control (As it was in 2004) * Security Misconfiguration * Sensitive Data Exposure * Insufficient Attack Protection (NEW) * Cross-Site Request Forgery (CSRF) * Using Components with Known Vulnerabilities * Underprotected APIs (NEW)
OWASP Top 10 comparsion table for 2013 vs 2017
|A1 - Injection||A1 - Injection|
|A2 - Broken Authentication and Session Management||A2 - Broken Authentication and Session Management|
|A3 - Cross-Site Scripting (XSS)||A3 - Cross-Site Scripting (XSS)|
|A4 - Insecure Direct Object References - Merged with A7||A4 - Broken Access Control (Original category in 2003⁄2004)|
|A5 - Security Misconfiguration||A5 - Security Misconfiguration|
|A6 - Sensitive Data Exposure||A6 - Sensitive Data Exposure|
|A7 - Missing Function Level Access Control - Merged with A4||A7 – Insufficient Attack Protection (NEW)|
|A8 – Cross-Site Request Forgery (CSRF)||A8 – Cross-Site Request Forgery (CSRF)|
|A9 – Using Components with Known Vulnerabilities||A9 – Using Components with Known Vulnerabilities|
|A10 – Unvalidated Redirects and Forwards -Dropped||A10 – UnderprotectedAPIs (NEW)Release NotesRN|
|App Specific||Easy||Widespread||Easy||Severe||App/Business Specific|
|App Specific||Average||Common||Average||Moderate||App/Business Specific|
|App Specific||Difficult||Uncommon||Difficult||Minor||App/Business Specific|
If you like this information then please star this repository on Github at Software Security