Notes - MCS
Robust Software
Notes - MCS
Robust Software
  • Robust Software
  • Secure Software Design Principles
    • Motivation
    • Secure and Resilient/Robust Software
    • Best Practices for Resilient Applications
    • Designing Applications for Security and Resilience
    • Architecture for the Web/Cloud
  • Software Security Lifecycle
    • Motivation
    • Secure Development Lifecycle
    • Software Security Touchpoints
    • Software Assurance Forum for Excellence in Code (SAFECode)
    • Secure SW Lifecycle Processes Summary
    • Adaptations of the Secure Software Lifecycle
    • Assessing the Secure Software Lifecycle
    • Recommendations
  • Software Quality Attributes
    • Motivation
    • Software Quality Assurance
    • Software Quality Standards
    • Software Quality Attributes
    • Extra Software Quality Assurance Properties
  • Security Requirements
    • Motivation
    • Security Requirements
    • Threats
    • Defenses
    • Confidentiality
    • Integrity
    • Availability
    • What about other goals/properties?
    • Security Requirements Engineering
    • Types of Security Requirements
    • Security Policy
    • Precision
    • Completeness and Consistency
    • Examples of Non-Functional Requirements
    • Goals and Requirements
    • Measures
    • Requirements Interaction
    • Natural Language Requirements
    • Best Practices
  • Common Software Attacks
    • Objectives
    • 10 Major Cyber-Attacks of 21st Century
    • Software Security Basics
    • Defenses Methods
    • SANS SWAT Checklist
  • Safe Programming
    • Secure Coding Practices
    • Top 10 Secure Coding Practices (CERT/SEI)
    • 7 Pernitious Kingdoms
  • Robustness, PenTest, Fuzzy and Static Code Analysis
    • Security/Robustness Testing
    • Robustness Tests Checklist Example
    • Penetration Testing
    • Penetration Testing Roadmap
    • Tools
    • Fuzz Testing
    • Static Code Analysis
    • Side Channels
  • Safety (and Security)
    • Safety
    • A safety Lifecycle Example
    • Risk Management Process
    • System Definition
    • Hazard Identification and Classification
    • Desk-based Hazard Identification
    • Workshop-based Hazard Identification
    • HAZOP
    • Hazard Identification and Classification
      • Broadly acceptable risks
    • Risk Evaluation and Risk Acceptance
    • Use of codes of practice
    • Use of reference system
    • Explicit risk estimation
    • Qualitative risk estimation
    • Quantitative risk estimation
    • Safety measures
    • Safety requirements
    • Hazard Management
    • Hazard life cycle
    • Independent Assessment
    • Safety Plan
    • Safety Case
    • FMEA Example
    • DevSecOps
Powered by GitBook
On this page
  1. Secure Software Design Principles

Architecture for the Web/Cloud

Why design for failure when nothing fails? (everything fails...)

Build security in all layers. (do not trust)

Leverage alternative processing/storage. (redundancy pays off)

Implement elasticity. (flexibility, scalability, easy restart)

Think parallel. (decoupling data from computation, load balancing, distribution)

Loose coupling helps. (do not reinvent the wheel, use existing solutions).

Don't fear constraints, solve them. (memory, CPU, distribution, ...)

Use caching. (performance)

Design Best Practices

  • Input handling validation.

  • Prevent Cross-Site Scripting.

  • Prevent SQL Injection attacks.

  • Apply authentication.

  • Cross-Site Request Forgery mitigation.

  • Session management (log-out or cookie attacks).

  • Protect access control attacks (admin interfaces).

  • Use cryptography.

XSS (Cross-Site Scripting) attacks enable attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy.

XSRF is a type of malicious exploit of a website where unauthorized commands are submitted from a user that the web application trusts. there are many ways in which a malicious website can transmit such commands, specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site. CSRF exploits the trust that a site has in a user's browser.

  • Apply error handling

  • Protect against known attacks (e.g. AJAX or Flash)

  • Initialize variables properly.

  • Do not ignore values returned by functions.

  • Avoid integer overflows.

Last updated 1 year ago