Defence-in-Depth

The principle of defence in depth is to have layered security mechanisms. Having multiple security mechanisms in place means if there is an attack on your system, hopefully only one mechanism has been breached, and there are others to continue protecting your system (owasp 2015). When adding extra defence mechanisms additional risks should be evaluated. For example, changing password requirements to force lengthy complicated passwords may result in users physically writing passwords down on pieces of paper, this may create a greater risk than requiring a shorter, less complicated password (owasp 2015). A two-step authentication process would be better in this scenario, banks use two step authentication processes when a user is withdrawing money from an ATM, the first is something you possess – the ATM card, and secondly, something you know – your pin number. Two-step verification is increasingly seen in email and social networking sites and other websites requiring improved security. The two-step authentication for websites is usually a username and password, coupled with a code that is sent to the users phone. The advantage to this two-step method is even if the password is guessed or stolen, without the code sent to the account holder’s mobile phone, the attacker will be unable to login (Barnatt 2014). Applications where users login via username and password must have several additional security mechanisms in place. These include session management, authentication using tokens, and having restricted access measures in place. It is important to restrict the application to the lowest possible level of privileges when accessing the database. When the majority of the access to the database is read only, if an attacker is able to hijack a users account, they will be unable to write or delete important information from the database (Stuttard & Pinto 2011 p.342). Token authentication is another useful tool. Tokens are cryptographically signed by the server, which guarantees they have not been forged or altered (Barbettini 2016).

OWASP regularly compiles a list of the top 10 of the most critical web application security flaws. Thoroughly understanding these top 10 threats and implementing layered protections to defend against them is crucial in any application. 


OWASP Top 10 Application Security Risks – 2013 Report

1. Injection
Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

2.Broken Authentication and Session Management
Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.

3. Cross-Site Scripting (XSS)
XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

4. Insecure Direct Object References
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

5. Security Misconfiguration
Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

6. Sensitive Data Exposure
Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

7. Missing Function Level Access Control
Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.

8. Cross-Site Request Forgery (CSRF)
A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

9. Using Components with Known Vulnerabilities
Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.

10. Unvalidated Redirects and Forwards
Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.

References
Barbettini N, 5 August 2016, Stormpath, online video, accessed 11 September 2016.
https://www.youtube.com/watch?v=5uIenyM55gU 

Barnatt C, 7 July 2014, Explaining Computers, online video, accessed 14 September 2016.
https://www.youtube.com/watch?v=AIOUlQeQbNM 

OWASP, 2013, The ten most critical web application security risks. PDF download link
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project 

OWASP, 14 August 2015, Defense in depth, accessed 13 September 2016.
https://www.owasp.org/index.php/Defense_in_depth 

Stuttard D & Pinto M, 2011, The Web Application Hacker’s Handbook, Wiley Publishing, Inc. Indianapolis, Indiana USA.

Domain Driven Design

“As software developers, we fail in two ways: we build the thing wrong, or we build the wrong thing.”  – Steven Smith, 2014.

Domain Driven Design is an approach to build better software applications. Nillsson and Green (2014) describe it as a collaboration between domain experts and software developers. This is contrary to data driven design, which has no contact between designers and developers. Traditionally, senior developers would write the framework, then hand off the domain to be written by the less experienced developers (Friberg 2015). Domain Driven Design turns this concept on its head by making the domain the crucial component. The Domain Driven Design approach begins with opening communication between software developers and domain experts, this gives the developers a chance to fully explore what the client understands their needs are and enables the developers to begin thinking about code that would perfectly meets those needs. It is important to understand the context to be able to add it to the code, if it is important to the client, it should be in the code (Green & Nillsson 2014). At this stage the developers can begin to paint the overall picture of the subsystem. User stories are created with specific examples to present to the domain expert. It is important that software developers step outside of coding language and use ubiquitous language with conversations between the software developers and domain experts (Friberg 2015, Green & Nillsson 2014). This ubiquitous language is then used in all aspects including the code, design documents and conversations, thus preventing confusion and ensuring both teams have a clear understanding of the design and processes (Smith 2014). Once user stories are agreed upon, it is time to sketch them out. These sketches can be scenarios, storyboards, simple coded prototypes or UML. It is important to utilise the strong communication foundation and ensure the storyboard scenarios meet the client’s needs. Only then can writing the code begin. The initial stage of coding is used to test the system by using the scenarios as test cases (Green & Nillsson 2014). These scenarios are tested one by one adapting and adding classes and components as needed. It is an iterative process allowing the developers to improve and better understand the client’s requirements. The Domain Driven Design approach results in greater flexibility, better understanding of the problem by the customer, and better communication of the clients needs by the developer.

References
Friberg R, 21 September 2015, DotNetFringe Conf, online video, accessed 12 September 2016.
https://www.youtube.com/watch?v=0WO3H_MOjrI

Green R & Nillsson J, 18 September 2014, TechEd, online video, accessed 12 September 2016.
https://www.youtube.com/watch?v=FVGE00rUJow

Smith S, 28 September 2014, Domain-Driven Design with ASP.NET MVC, accessed 12 September 2016.
http://www.slideshare.net/ardalis/ddd-aspnet-mvc

HTTP Protocol

Hypertext Transfer Protocol (HTTP) is the core communications protocol used to access the web. Originally developed for retrieving static text, it has been expanded to enable support for more complex applications (Stuttard & Pinto 2011, p.39).
HTTP functions as a request-response protocol between a client and a server, where the client sends a request to the server, and the server returns a response (w3Schools 2016). A HTTP message has both requests and responses. The request takes three items, the HTTP method, the request Uniform Resource Locator (URL) and the HTTP version being used (typically version 1.1).
It is important to understand the errors that can occur with a response, and what they mean in order to rectify the issue. Status messages: 100 series covers information about servers receiving requests, and of asking the server to switch protocols.
200 series covers successful requests, being the request is OK, has been fulfilled, and has been successfully processed.
300 series covers redirection, there can be link lists for the user to select a link, or a link to the page having moved permanently or temporarily.
400 series covers client error, which can be due to syntax error (typo), unauthorised or forbidden request, and the infamous 404 not found.
500 series covers server error, which can be internal, not implemented, unavailable or timed out. (w3Schools 2016)

HTTP methods GET and POST are extremely important as they can affect an applications security if overlooked (Stuttard & Pinot 2011, p.42).
The Get method is used to request data from specified resources. These Get requests remain in the browser history and can be bookmarked, so should not be used with sensitive data – passwords etc. The data is visible to all as it is displayed in the URL (w3Schools 2016).
The Post method is used to submit data to be processed to a specified resource. Post requests should be used when an action is being performed.
Post requests do not remain in the browser and cannot be bookmarked, so is a little safer than Get. No data in displayed in the URL. Data submitted via the Post method will be resubmitted if the user presses the ‘Back’ or ‘reload’ buttons on the browser, it is important to alert the user that the information will be resubmitted (w3Schools 2016).

References
Stuttard D & Pinto M, 2011, The Web Application Hacker’s Handbook, Wiley Publishing, Inc. Indianapolis, Indiana USA.

W3 Schools, 2016, accessed 15th August 2016
http://www.w3schools.com/tags/ref_httpmethods.asp

Full Stack Development

Full stack development combines both front end and back end development. From the highest resolution of the design and interface, to the lowest resolution of bits and bytes. Full stack means developers who are comfortable with front end and back end technology (Fekete 2014). Being a full stack developer does not necessarily mean you need to an expert in both front end and back end. As Pastrana (2015) states, while it is better to specialise in one area, which could be front end or back end code, it is best if you are able to understand enough of the other areas so that you can properly prepare your work to be handed to the person responsible for implementing the next stage. It is also advisable to understand all areas required so you are able to problem solve or at least know who to communicate with about the problem. Being a full stack developer is desirable in start-up and small companies where there may only be one or two developers to create the project, but less common in workplaces that a team to create a project (Fekete 2014).

Front-end development is what the interacting human will see - websites, apps. This includes coding the interface using HTML, CSS and JavaScript.
The back end or server side is hidden from the user. The back end consists of web servers, database, and server side code. Being a full stack developer doesn't mean you have to be an expert in every language. Each individual will have strengths/weaknesses and preferences, it is, however, important to have a solid understanding of each component so to enable proficient communication between the developers in each section (Fekete 2014).
A .NET full stack developer should understand :

ASP.NET stack development

Webpages stack c# + html embedded

Web form ASP

Mvc – model view controller – isolates business logic from the user interface

API – RESTful HTTP services

JSON file – JavaScript object notation

Web app – provides data and the way to display it

Web service – provides data to the browser

References

Fekete G, 22 September 2014, Site Point, accessed 3^rd August 2016

https://www.sitepoint.com/full-stack-developer/ 

Pastrana O, 15 June 2015, Platzi Team, online video, accessed 3^rd August 2016

https://youtu.be/qZb0k4NSzGY 

Dependency Injection

Dependency injection provides the objects that an object needs (dependencies) rather than constructing them itself. Dependency injection uses the dependency inversion principle of code depending upon abstractions (usually an interface) rather than directly depending upon the dependency (Ferrara 2013). A developer no longer needs to instantiate with the new operator from inside of the class. Instead, it can be taken as a constructor parameter or via a setter (Ferrara 2013). Whilst containers are no longer needed with dependency injection, they do make life a lot easier for the developer. Dependency injection containers are a map of dependencies the class needs. The container will also have the logic to create dependencies that haven't been created yet. So instead of creating the classes yourself, you can ask the container for new instances (Ferrara 2013). Dependency injection promotes loose coupling between modules to provide a way to switch code modules being used without the need to build and restart the entire application or parts of it. This could be done by using either a configuration file or by reading dependency injection information from a database table (Jhangra 2016).

 

A benefit of using dependency injection design pattern is that it enables you to ask the container for new instances of a class, saving you from creating them yourself. A developer can also inject additional code between dependencies, for example, validation logic, which saves the developer from having to write this logic for every class. Another benefit of using dependency injection design pattern is that it can make testing a lot easier. Dependency injection allows the developer to replace complex dependencies, such as databases, with mocked implementations of those dependencies, allowing you to isolate the code being tested (Culp 2011).

By using dependency injection, you are able to write cleaner and more efficient code, that is easier to read, easier to test, and easier to modify in the future.

References

Culp A, June 2011, Microsoft, accessed 15^th August 2016

https://msdn.microsoft.com/en-us/library/hh323705(v=vs.100).aspx 

 

Ferrara A, 9 January 2013, online video, accessed 3^rd August 2016

https://youtu.be/IKD2-MAkXyQ 

Jhangra N, 16 June 2016, Code Project, accessed 3^rd August 2016-08-17

http://www.codeproject.com/Articles/1106838/Dependency-Injection-Scenarios-in-Asp-Net-Mvc 

Helpful link

Shimoon A, 14 October 2015, dotnetliberty, online video, accessed 3^rd August

https://youtu.be/5A2UxMGA58g

About me

My name is Kate, I live in Sydney, Australia.
I have a bachelors degree in industrial design and I'm currently studying programming.
My interest in programming sparked when I studied human computer interaction - learning about UI (User Interface) and how to make applications and websites intuitive for the user. Already competent in graphical components, I was interested in how the back end worked.
My hobbies include travelling, cooking, reading, and watching movies and TV.