Static and dynamic verification of indirect data sharing in component based applications
Download
1 / 55

Static and Dynamic Verification of Indirect Data Sharing in Component-based Applications - PowerPoint PPT Presentation


  • 132 Views
  • Uploaded on

Static and Dynamic Verification of Indirect Data Sharing in Component-based Applications. PhD Defense Lieven Desmet 9 January 2007. Overview. Introduction Problem statement Static verification of indirect data sharing Static and dynamic verification Related work

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Static and Dynamic Verification of Indirect Data Sharing in Component-based Applications' - mahsa


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Static and dynamic verification of indirect data sharing in component based applications

Static and Dynamic Verification of Indirect Data Sharing in Component-based Applications

PhD Defense Lieven Desmet

9 January 2007


Overview
Overview Component-based Applications

  • Introduction

  • Problem statement

  • Static verification of indirect data sharing

  • Static and dynamic verification

  • Related work

  • Conclusion and future work


Overview1
Overview Component-based Applications

  • Introduction

  • Problem statement

  • Static verification of indirect data sharing

  • Static and dynamic verification

  • Related work

  • Conclusion and future work


Context
Context Component-based Applications

  • Modern software systems:

    • Quite complex

    • Composed of reusable components

  • Common architectural patterns to achieve loose coupling:

    • Pipe-and-filter style

    • Data-centered style


Pipe and filter style
Pipe-and-filter style Component-based Applications

  • The software is composed as a chain of components (filters), connected to each other by means of pipes

    • The invocation chain (control flow) follows the pipe

    • The dataflow follows the invocation chain by passing parameters at each invocation

  • To ease the composition, uniform interfaces are often used


Indirect data sharing

Comp Component-based Applications

Comp

Comp

Shared data

Comp

Comp

repository

Comp

Indirect data sharing

  • Data-centered style:

    • Central data repository

    • Components can read and write data to the repository

    • Components share data through the shared data repository


Calendar composition example

Shared data repository Component-based Applications

associated with the request

conflicts

meeting

Calendar composition example

/

addMeeting

AddMeeting

AddedMeeting

EmailNotifica

success

success

View

tionAction

Action

AddMeeting

fail

FailedView


Semantical dependencies

Shared data repository Component-based Applications

associated with the request

conflicts

meeting

/

addMeeting

AddMeeting

AddedMeeting

EmailNotifica

success

success

View

tionAction

Action

AddMeeting

fail

FailedView

Semantical dependencies

  • Breaking these semantical dependencies typically leads to run-time errors!


Overview2
Overview Component-based Applications

  • Introduction

  • Problem statement

    • DiPS+ RADIUS implementation

    • Duke’s BookStore application

    • Goal and scope of the thesis

  • Static verification of indirect data sharing

  • Static and dynamic verification

  • Related work

  • Conclusion and future work


  • Dips distrinet protocol stacks

    shared repository Component-based Applications

    packet

    Functional

    Functional

    Component

    Component

    control flow

    DiPS+ (DistriNet Protocol Stacks)

    • Rapid prototyping framework for protocol stacks

    • In-house developed in Java

    • Stable core with various research extensions:

      • Self-adapting concurrency (DMonA)

      • Run-time reconfiguration (CuPS, NeCoMan)


    Dips radius implementation

    9 Component-based Applications

    8

    7

    3

    10

    6

    4

    5

    1

    11

    12

    2

    1 udp.sourceIP (InetAddress)

    7 radius.authenticator

    (byte[])

    2 udp.sourcePort (Integer)

    8 radius.attributeListAttributeList)

    3 radius.nasSecret (byte[])

    9 radius.replyAttributeList (AttributeList)

    4

    radius.radiusPacket (byte[])

    10

    radius.requestAuthenticator (byte[])

    5 radius.code (byte)

    11 udp.destinationIP (InetAddress)

    6 radius.identifier (byte)

    12 udp.destinationPort (Integer)

    DiPS+ RADIUS implementation

    Radius Accounting

    AccountingReply

    AccountingRequest

    Accounter

    Preparator

    AuthenticatorChecker

    RadiusAttribute

    RadiusAttributeParser

    Constructor

    RadiusHeader

    RadiusHeaderParser

    Constructor


    Dips radius implementation1

    byte Component-based Applications

    byte[]

    !

    !

    DiPS+ RADIUS implementation

    Radius Accounting cvs

    cvs snapshot: 30/06/2003 12:24

    AccountingReply

    AccountingRequest

    Accounter

    Preparator

    AuthenticatorChecker

    8

    7

    RadiusAttribute

    RadiusAttributeParser

    3

    ClassCastException

    Constructor

    !

    10

    4

    6

    5

    RadiusHeader

    RadiusHeaderParser

    Constructor

    1

    2

    12

    1'

    2'

    NullPointerException

    1 udp.sourceIP (InetAddress)

    7 radius.authenticator

    (byte[])

    2 udp.sourcePort (Integer)

    8 radius.attributeListAttributeList)

    1' udp.senderIP (InetAddress)

    3 radius.nasSecret (byte[])

    9 radius.replyAttributeList (AttributeList)

    2' udp.senderPort (Integer)

    4

    radius.radiusPacket (byte[])

    10

    radius.requestAuthenticator (byte[])

    5 radius.code (byte)

    11 udp.destinationIP (InetAddress)

    6 radius.identifier (byte)

    12 udp.destinationPort (Integer)


    Duke s bookstore application

    /bookstore Component-based Applications

    /bookdetails

    /bookcatalog

    Server-side

    user state

    /bookcashier

    Client

    Server

    protocol

    /bookreceipt

    /bookshowcart

    Web Server

    Duke’s BookStore application

    • E-commerce site bundled with the J2EE 1.4 tutorial

    • Reactive client/server interaction


    Shared data interactions
    Shared data interactions Component-based Applications

    • Session repository with 3 data items:

      • messages (ResourceBundle)

      • cart (ShoppingCart)

      • currency (Currency)

      • read

      • def. read/write

      • cond. def. read/write


    Identified problems
    Identified problems Component-based Applications

    • BookStoreServlet is not executed first:

      • NullPointerException on retrieval of ‘messages’ data item

  • OrderFilter/ReceiptServlet are executed before cart and currency are stored to the repository

    • NullPointerException on retrieval of ‘cart’ and ‘currency’ data items


  • Desired composition property
    Desired composition property Component-based Applications

    • No broken data dependencies on the shared repository

      • A shared data item is only read after being written on the shared repository

      • For each read interaction, the data item present on the shared repository is of the type expected by the read operation

    NullPointerException

    ClassCastException


    Goal and scope of this thesis
    Goal and scope of this thesis Component-based Applications

    • Goal:

      • Eliminate run-time errors by formally guaranteeing the ‘no broken data dependencies’ property

  • Scope:

    • Component-based software with indirect data sharing

    • Deterministic and reactive software compositions

  • Important non-functional criteria:

    • Reasonable overhead

    • Applicable to real-life applications


  • Dependency analysis in gatormail
    Dependency analysis in GatorMail Component-based Applications

    • GatorMail

      • Open-source webmail application built upon Struts

      • 20K lines of code

      • 65 components

    • Analysis results:

      • 65 components reused in 52 request processing flows

      • 1369 hidden interactions with the shared repository

      • 147 declarative control flow transitions


    Complex dependency management
    Complex dependency management Component-based Applications

    • Composition: /saveAddresses.do


    Complex dependency management1
    Complex dependency management Component-based Applications

    1 of the 52 compositions in GatorMail

    107 interactions with the shared repository

    10 control flow transitions


    Overview3
    Overview Component-based Applications

    • Introduction

    • Problem statement

    • Static verification of indirect data sharing

      • Solution overview

      • GatorMail validation experiment

  • Static and dynamic verification

  • Related work

  • Conclusion and future work


  • Solution
    Solution Component-based Applications

    • Our approach uses static verification to guarantee that the no broken data dependencies property holds in a given composition

    • Verification is based on component contracts instead component implementations

    • 2 steps:

      • Identify interactions

      • Statically verify composition property


    Solution overview
    Solution overview Component-based Applications

    Input artifact

    Generated artifact

    Checking

    specification –

    implementation

    compliance

    Component

    implementation

    Component

    specification

    Composition-

    specific

    property

    verification

    Deployment

    information


    Component contracts
    Component contracts Component-based Applications

    • Specify the component’s interactions with the shared repository

    • Specify the possible declarative forwards

    Shared data repository

    associated with the request

    conflicts

    meeting

    /

    addMeeting

    AddMeeting

    AddedMeeting

    EmailNotifica

    success

    success

    View

    tionAction

    Action

    AddMeeting

    fail

    FailedView


    Addmeetingaction contract
    AddMeetingAction contract Component-based Applications

    //spec: forwards {“success”, “fail”};

    //spec: writes {Meeting meeting};

    //spec: on forward == “fail” also writes {Vector conflicts};

    Automatically translated into Java Modeling Language (JML)

    public class AddMeetingAction extends Action {

    //@ also

    //@ requires request != null;

    //@ ensures request.getDataItem("meeting") instanceof Meeting;

    //@ ensures \result == "fail" ==> request.getDataItem("conflicts") instanceof Vector;

    //@ ensures \result == "success" || \result == "fail";

    public String execute(Request request, Form form);

    }

    in order to be verified by existing verification tools


    Composition specific verification
    Composition-specific verification Component-based Applications

    Component

    specification

    • Main idea:

      • Verify if the composition property holds for each possible execution path in the composition

    • Concrete:

      • Generate a composition-specific check method, enrolling the possible run-time execution paths

      • Use existing verification tools to verify the composition property for each execution path

    Composition-

    specific

    property

    verification

    Deployment

    information


    Enrolling the execution paths
    Enrolling the execution paths Component-based Applications

    • Composition example:

    AddMeeting

    Action

    success

    EmailNotifica

    tionAction

    AddMeeting

    View

    success

    fail

    AddMeeting

    FailedView


    Enrolling the execution paths1
    Enrolling the execution paths Component-based Applications

    //@ requires request != null;

    public void check_addMeeting(Request request, Form form){

    AddMeetingAction addMeetingAction = new AddMeetingAction();

    EmailNotificationAction emailNotificationAction = new EmailNotificationAction();

    AddedMeetingView addedMeetingView = new AddedMeetingView();

    FailedAddedMeetingView failedAddedMeetingView = new FailedAddedMeetingView();

    String forward1 =addMeetingAction.execute(request,form);

    if(forward1.equals("success")){

    String forward2 =emailNotificationAction.execute(request,form);

    if(forward2.equals("success")){

    addedMeetingView.execute(request,form);

    } else { //@ unreachable; }

    } else if(forward1.equals("fail")){

    failedAddedMeetingView.execute(request,form);

    } else { //@ unreachable; }

    }


    Evaluation
    Evaluation Component-based Applications

    • Prototype implementation:

      • Step1:

        • JML as intermediate specification language

        • Our problem-specific contracts are automatically translated into JML

        • ESC/Java2 as static verification tool

      • Step 2:

        • Composition-specific verification is automatically generated from the deployment information

        • ESC/Java2 as static verification tool

    • Evaluation on the GatorMail webmail application

    • Presented approach was applicable with only some slight refinements


    Experiment results
    Experiment results Component-based Applications

    • JML annotation overhead

      • At most 4 lines of problem-specific annotation

    • Verification performance:

      • Modular verification

      • The verification takes up at 700 seconds per component


    Conclusion
    Conclusion Component-based Applications

    • We are able to guarantee the desired composition properties in a given composition

      • With minimal formal specification

      • Using existing reasoning tools

      • In a reasonable amount of time

    • Proposed solution

      • Applicable to real-life applications

      • Scalable to larger applications (if the complexity of the individual components remains equivalent)


    Overview4
    Overview Component-based Applications

    • Introduction

    • Problem statement

    • Static verification of indirect data sharing

    • Static and dynamic verification

      • Solution overview

      • Duke’s BookStore validation experiment

  • Related work

  • Conclusion and future work


  • Solution1
    Solution Component-based Applications

    • Our approach uses static and dynamic verification to guarantee that the no broken data dependencies property holds in a given, reactive composition

    • 3 steps:

      • Identify interactions

      • Statically verify composition property

      • Enforce underlying assumptions at run time


    Solution overview1
    Solution overview Component-based Applications

    Input artifact

    Generated artifact

    Application

    implementation

    Checking

    specification –

    implementation

    compliance

    Application

    specification

    Application-specific

    protocol

    verification

    Deployment

    information

    Intended client/

    server protocol

    Run-time

    protocol

    enforcement

    Online web

    traffic


    Step 1
    Step 1 Component-based Applications

    Application

    implementation

    Checking

    specification –

    implementation

    compliance

    Application

    specification

    • Component contracts specify interactions with the shared repository:

    • //spec: reads {ResourceBundle messages, Nullable<ShoppingCart>cart,

    • Nullable<Currency> currency} from session;

      //spec: writes {cart == null => ShoppingCart cart} on session;

      //spec: possible writes {currency == null => Currency currency} on session;


    Step 2
    Step 2 Component-based Applications

    Application

    specification

    Application-specific

    protocol

    verification

    Deployment

    information

    Intended client/

    server protocol

    • Simulate all possible client-server interactions that comply to the intended client/server protocol

    • Use static verification to formally guarantee that the no broken data dependency property is not violated


    Intended client server protocol
    Intended client/server protocol Component-based Applications

    PROTOCOL := /bookstore + SERVLET A + RECEIPT

    RECEIPT := ( SERVLET B + SERVLET + /orderfilter + /bookreceipt ) | nil

    SERVLET := SERVLET A | SERVLET B

    SERVLET A := /bookstore | /bookdetails | /bookshowcart | /banner | nil

    SERVLET B := /bookcatalog | /bookcashier


    Application specific verification
    Application-specific verification Component-based Applications

    // …

    if (random.nextBoolean()){

    switch(random.nextInt()){

    case 0: cashier .doGet(request,response); break;

    default: catalog.doGet(request,response); break;

    }

    while(random.nextBoolean()){

    switch(random.nextInt()){

    case 0: showcart.doGet(request,response); break;

    case 1: catalog.doGet(request,response); break;

    case 2: cashier .doGet(request,response); break;

    case 3: bookstore.doGet(request,response); break;

    case 4: bookdetail.doGet(request,response); break;

    default: break;

    }

    }

    // …

    }


    Step 3
    Step 3 Component-based Applications

    Intended client/

    server protocol

    Run-time

    protocol

    enforcement

    Online web

    traffic

    • Limit traffic to the intended client/server protocol

    • Typical use of a Web Application Firewall (WAF) in protecting against forceful browsing


    Evaluation1
    Evaluation Component-based Applications

    • Prototype implementation:

      • Step1:

        • JML as intermediate specification language

        • Our problem-specific contracts are automatically translated into JML

        • ESC/Java2 as static verification tool

      • Step 2:

        • Application-specific verification is automatically generated from the EBNF protocol specification

        • ESC/Java2 as static verification tool

      • Step 3:

        • J2EE filter as a proof-of-concept flow enforcement WAF

    • Evaluation on the Duke’s BookStore application from the J2EE 1.4 tutorial


    Experiment results1
    Experiment results Component-based Applications

    • Annotation overhead:

      • At most 4 lines in our problem-specific annotation

  • Verification performance:

    • Static verification took at most 4 minutes per component


  • Experiment results2
    Experiment results Component-based Applications

    • Run-time overhead:

      • Experiment:

        • sequence of 1000 visitors

        • on average 6 requests per session

        • 2% of the users applied forceful browsing

    • Measured run-time overhead of 1.3%

  • In comparison:

    • In a previous prototype without static verification, a run-time overhead of approximately 20% was measured


  • Conclusion1
    Conclusion Component-based Applications

    • We are able to guarantee the desired composition properties in a given, reactive composition

      • With minimal formal specification

      • Using existing reasoning tools

      • In a reasonable amount of time

    • Proposed solution

      • Applicable to real-life applications

      • Scalable to larger applications (if the complexity of the individual components and the protocol remains equivalent)

    • We leverage WAFs to protect application-specific implementation bugs


    Overview5
    Overview Component-based Applications

    • Introduction

    • Problem statement

    • Static verification of indirect data sharing

    • Static and dynamic verification

    • Related work

      • Software architectures

      • Components and contracts

      • Formal verification in web applications

      • Alternative approaches

  • Conclusion and future work


  • Software architectures
    Software architectures Component-based Applications

    • Architectural styles

      • Pipe-and-filter, data-centered, ... (Shaw & Garlan, 1996)

  • Architectural Description Languages (ADLs)

    • Darwin (Magee and Kramer, 1996),Wright (Garlan, 1994),xADL (Dashofy et al., 2001), ...

  • Architectural dependency analysis

    • Dependency models (Vieira and Richardson, 2002), Event invocation analysis (Magee and Kramer, 1996), ...

  • Coupling between architecture and implementation

    • ArchJava (Aldrich, 2003)


  • Components and contracts
    Components and contracts Component-based Applications

    • Component-based software development

      • Component-oriented programming

        • Szyperski et al., 1998 & 2002

    • Contract-aware components

      • Beugnard et al., 1999

  • Design by Contract

    • Eiffel programming language

      • Meyer, 1986

  • Spec# programming system

    • Barnett et al., 2004


  • Formal verification in web applications
    Formal verification in web applications Component-based Applications

    • Protection against injection attacks and XSS

      • Run-time tainting

        • Pietraszek and Vanden Berghe (2005), Nguyen-Tuong et al. (2005), Halder et al. (2005), ...

    • Static analysis

      • Livshits and Lam (2005), Jovanovic et al. (2005)

  • Combination of static information flow analysis and run-time guards:

    • Huang et al. (2004)

  • Firewall configuration analysis

    • Consistency between different firewalls and IDS configurations

      • Uribe and Cheung (2004)

  • Rule consistency and reduction

    • Golnabi et al. (2006)


  • Alternative approaches
    Alternative approaches Component-based Applications

    • Pluggable type systems

      • Bracha, 2004

      • Andreae et al., 2006

  • Better programming techniques

    • Defensive programming

    • Typed repositories


  • Overview6
    Overview Component-based Applications

    • Introduction

    • Problem statement

    • Static verification of indirect data sharing

    • Static and dynamic verification

    • Related work

    • Conclusion and future work

      • Contributions

      • Future work

      • Challenges and opportunities


    Contributions
    Contributions Component-based Applications

    • Good insights in dependency management by several case studies

    • Definition of the ‘no broken data dependencies’ composition property

    • Static verification of the property in deterministic software compositions

    • Combination of static and dynamic verification of the property in reactive software compositions


    Validations
    Validations Component-based Applications

    • The GatorMail case study

      • Validation in deterministic software compositions

      • Low annotation cost

      • Reasonable verification time

      • Applicable to real-life applications (>20 KLoc app)

  • The BookStore case study

    • Validation in reactive software compositions

    • Low annotation cost

    • Reasonable verification time (static & dynamic)


  • Future work short term
    Future work: short term Component-based Applications

    • Support concurrent server processing by adding a fine-grained concurrency model

      • Simple model: introduce lock per user session

      • More fine-grained: maximise parallelism based on disjunct interactions with the repository

  • Enrich the intended client/server protocol by incorporating input parameters and cookies

    • Formally verify the effectiveness of applied input validation checks, e.g. in WAFs


  • Future work longer term
    Future work: longer term Component-based Applications

    • Generalise the approach of problem-specific annotation and verification

      • Application to other composition properties

      • Composability of different properties

      • Compare to alternative approaches, such as pluggable type systems

  • Valorise research in a developer’s tool

    • Specification inference

    • Protocol inference

    • Useful feedback to the developer

    • Integration into IDE


  • Challenging opportunities
    Challenging opportunities Component-based Applications

    “Formal verification will become a key enabler in future software engineering”

    • Software systems become even more loosely-coupled, e.g. by using late and dynamic composition

    • Appealing synergies between formal verification and end-to-end attestation

    • Appealing synergies between formal verification and model driven engineering


    Static and dynamic verification of indirect data sharing in component based applications1

    Thank you! Component-based Applications

    Static and Dynamic Verification of Indirect Data Sharing in Component-based Applications

    PhD Defense Lieven Desmet

    9 January 2007


    ad