Aspect Security - RaviShekhar Gopalan - Prof. Lieberherr Software Security (CSG379)

Topics Covered

Topics  Short Security Overview  Motivation for this project  What is this project?  Implementation  Future Work  References

Security Overview

Security in Software Engineering A non-functional requirement Applied as a patch at the end of SDLC Not a design-consideration Preference for non-invasive techniques Not a prime focus during development Leads to a disconnection between development and “security” cycle

Types of Security Domain Level Security Is dependent on an application Is dependent on an application Similar to Business Rules Similar to Business Rules Security policies, ACLs – Non-invasive Store them as rules in config files Store them as rules in config files E.g. xml files in J2EE E.g. xml files in J2EE Provided by language Not the focus anywhere Not the focus anywhere This project is about improvements to the security features provided by the language

Security provided by the language Language should provide features for security Similar to “public”, “private” there should be some “const” keyword similar to C++ Every method should declare its behavior For e.g. we might have a new set of keywords Immutable Immutable Inspector Inspector Mutator Mutator

Motivation

Enter AOP! Security loopholes may not be intentional Bug fixes may introduce security bugs More so with AOP (compartmentalization) Right time to correct in AOP whatever was not done in OOP Since AOP still in infancy, security focus can be imbibed

Aspect Security Aspects are powerful. Aspects are powerful. Need a controlled & safe way of aspect oriented development Need a controlled & safe way of aspect oriented development Need a stronger safety net than normal languages Need a stronger safety net than normal languages

Simple Demo !!

What is this project?

Ideally, …. Ideally, language should provide features for security Ideally, language should provide features for security Every method should declare its behavior Every method should declare its behavior If not, metadata will have to be used. If not, metadata will have to be used.

Requirements?? At the least, compiler should At the least, compiler should Warn if it can determine whether a possible security breach exists Warn if it can determine whether a possible security breach exists There exists possible loop-holes which can be exploited in future There exists possible loop-holes which can be exploited in future Guard against these by putting dynamic checks in place Guard against these by putting dynamic checks in place This is a bit ambitious, but not too much. This is a bit ambitious, but not too much.

What is a Secure Aspect? A secure aspect is an aspect which is secure A secure aspect is an aspect which is secure For object-oriented programs, an aspect should not For object-oriented programs, an aspect should not interfere with the OO part of the system interfere with the OO part of the system modify behavior of the object which it is trying to influence. modify behavior of the object which it is trying to influence. modify data of the object which it is trying to influence. modify data of the object which it is trying to influence.

What should a secure aspect do? A secure aspect should A secure aspect should Add behavior at a join point Add behavior at a join point Add checks for certain conditions Add checks for certain conditions Basically be an inspector Basically be an inspector

What a secure aspect should not do? A secure aspect should not A secure aspect should not Modify an object’s behavior at any join point Modify an object’s behavior at any join point Modify an object’s data at any join point Modify an object’s data at any join point Should not change an object’s hierarchy if the object is not open to change (……) Should not change an object’s hierarchy if the object is not open to change (……)

Implementation

How to do it? In order to determine the security aspects statically, step in at compile time influence the compiler with our security rules Security Rules can be hard-coded or in some XML file Rules in an XML file require development of a separate language syntax and its validation

Aspect Bench Compiler abc compiler from Oxford University Chosen because it is open-source Open and easy to extend Gives extension-writers the AST in objects which are easier to manipulate

abc Architecture

abc Modification Point

Proposed Change Compiler Front End Aspect Checker Static Weaving

Proof of Concept Aspect Checker checks aspects before weaving For this PoC, I am checking whether an aspect calls a setter method of the main class

Aspect Checker MainBankAccount::initialize() Set Account Id to 0 Aspect

Design of Aspect Checker GlobalAspectChecker BankAccountCheckerBankChecker AspectInfo abc Compiler AccountChecker Individual Checkers

Demo of Aspect Checker

Future Work

 Handle inter-type declarations  Handle weaving of aspect-checking code  Finalize design of AspectChecker

References

References   Building the abc AspectJ compiler with Polyglot and Soot – –abc Technical Report No. abc   abc : An extensible AspectJ compiler – –abc Technical Report No. abc   The abc scanner and parser, including an LALR(1) grammar for AspectJ

Thank You!!