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.

PSS - Peer Reviews

Lukas Cubirka
Sebastian Gregory
Stella Ho
Gabriel Ly
Dale Wakeham

PSS - Sydney Scoot

  

Sydney Scoot

Sydney Scoot is an electric scooter rental scheme targeting tourists visiting Sydney. The eye-catching stations scattered across the city allow users to undock electric scooters after scanning their licence and credit card, to explore the emerald city.

A vast majority of countries have high populations of scooter abled drivers. 5.2 million short-term visitors arrive in Australia every year. Sydney Scoot aims to capitalise on this by providing electric scooters to these short term visitors and allowing them to explore the city at their own pace.

Sydney Scoot is a Product Service System (PSS) that provides an interesting and competitive form of transport for visitors to Sydney in the following ways:

1. User autonomy

Sydney’s public transport can be a daunting experience, the buses have complicated zones and ticketing and can suffer from irregular timetables. The Sydney Scoot provides an opportunity for tourists to be completely independent. They do not have to adhere to timetables and are totally free to explore when/where/what they please. The Sydney Scoot electric scooters provide storage underneath the seat and in the top box for all shopping purchases and personal items.

2. Guilt free experience

The Sydney Scoot scooters are electrically powered. This means no tailpipe emissions and a nice quiet ride. The scooters provide a large kilometre range and have a short charging time. Just plug it back into the dock at your next destination and rest assured the scooter will be ready for your next travel leg. The Sydney Scoot hire terminal is solar powered and any additional power harnessed is channeled into the charging docks.

3. Easy access

The Sydney Scoot system has been designed to take the worry out of vehicle hire. There are no keys to lose or pin codes to forget, the whole system relies upon an RFID enabled credit card, which, once activated, is easily tapped onto the receiver panel on the docking station to release the scooter. Getting lost is another big concern in a foreign city, Sydney Scoot has alleviated this issue by providing built in GPS units on all the scooters.

4. Safety first

Sydney Scoot provides comfortable and high safety rated helmets. These helmets have fully washable lining and come complete with a flip down sun shield. The GPS system installed into the scooters links up with a bluetooth headset installed inside the helmet. This allows the directions from the GPS unit to be heard directly by the driver, ensuring they will never get lost. The Hire terminal has been design to be vandal resistant with a strong stainless steel front panel. The docking stations have RFID enabled locks, which sense the scooter being returned, and clamp the front wheel. The top of the terminals and docking stations are deliberately slanted to discourage waste from being discarded there.

In summation, the Sydney Scoot provides tourists with a unique way to explore this great city. The PSS allows for a streamlined, fun and unforgettable trip without the hassles associated with being in a foreign city.

Video Reflection: Who Killed the Electric Car?

Who Killed the Electric Car? (2006) Directed by Chris Paine is an insight into what happened to the electric car. After studies in 1989 found that 1 in 4 15-24 year olds living in Los Angeles had severe lung lesions and chronic raspatory disease, the Californian government had the insight in 1990 to create the Zero Emission Vehicle (ZEM) mandate stating that by 2008, 10% of new cars sold had to be electric. This then forced the car manufacturers to create electric cars. Despite the manufacturers resistance, they were mostly successful. The deeper issues here are the reluctance of the manufacturers to create products that require little servicing, need no oil changes, and have no need to regularly refuel on petrol.

This war on the electric car was about money. Making energy efficient cars that had no reliance on fossil fuels removed the need for big corporations. Poor tactics were used such as buying controlling shares in the battery company then preventing the battery creator from talking to the press about how great his batteries were. They used inferior batteries in the initial cars, even though superior battery technology was readily available. The cars were only available to lease, not to buy. Preventing any long-term ownership of the cars, and allowing the car manufacturers to repossess the electric cars whenever they pleased. Interested parties were informed of the many limitations of the cars when they inquired about leasing. Which as Chelsea Sexton states, “if you really want to sell a product, you don’t start out by listing the limitations of that product”. The advertisements created for these electric cars were haunting and eerie, not your typical car advertisement with a fast car and a pretty woman displayed on the bonnet.

Consumer groups started lobbying against the small tax increases used to build charging stations around the city of Los Angeles. Further investigation into these consumer groups, revealed that they were funded by oil companies. The Californian government had created a mandate to force car manufacturers to build electric cars but soon realised they had no way to enforce it. Pressure from the Bush administration to change the mandate and eventual legal action forced the Californian government to amend the mandate and provide a clause stating that the car companies need only comply, if there was a great consumer push for electric cars.

The documentary itself lists the factors to be blamed for the demise of the electric car. These are: the car companies, oil companies, California Air Resources Board, consumers, the government and the promise of hydrogen fuel cells, which would never eventuate.

What is utterly frightening about this documentary is the revelation of how the combined forces of the US federal government, the car manufacturers and the oil companies persuaded the consumers that electric cars are not the way of the future. Substantial tax rebates were offered to those who purchased the large SUV GM’s Hummer. Those they did not persuade, they simply reclaimed the cars and destroyed them. Leaving no trace, only memories of what once was, and what the world could have been.

A follow up documentary titled “Revenge of the Electric Car” was released in 2011.

Video Link

Image Link

Peer Reviews - Cormack Packaging

Rebecca Womersley
Deon Pazpinis

Mikee Ronquillo 

James Chen
Andrew Bae

Packaging Presentation

“O” Juice Bottle RATIONALE



Existing Juice packaging has many flaws. Many are difficult to open. Tetra paks contain straws that are hard to remove and insert. Pop top bottles encourage opening with teeth which can lead to damage.
The OJ juice bottle is a fun and quirky design for young children. It creates a unique and enjoyable way for children to drink juice.

The design consists of a unique “O” shaped bottle and an easy twist top. The bottle’s unique design is made for young children to enable ease of use through a comfortable and palpable “O” shape. This shape has been ergonomically designed to accommodate the 50mm hand width dimensions of 5 to 6 year olds. The large “O” shape allows easy grip and enables the children to tip the bottle up to drink with ease.

The lid comprises two parts. The white outer lid and the blue inner lid. These parts are connected with internal rings to prevent the top part of the lid being extricated and consequentially a choking hazard. The twist top lid has large ridges on the outside allowing children to easily twist the top up to drink, avoiding pulling, which can damage teeth. The inner lid has mini ramps which guide the outer lid when twisted to travel up and down, thus opening and closing  the lid. The twist top cap is water tight when closed.

The bottle and lids are made from food safe polypropylene. They have been designed with reuse in mind, as the bottle is refillable. When they do reach the end of their life, they are all the same material, and are easy to recycle.

Focus group

The results of the focus group are as follows.

Issues:
- Straw too short
- Lid needs tamper seal
- Lid could pop open in bag
- Lid too large for bottle
- Change material of bottle
- Graphics could be a problem to apply

Posters:
- Tech drawing confusing
- Show how foil pack is made
- Target market is missing
- How does the product fit in a lunch box
- Use smaller images
- Use more written explanations

Improvements:
- Add age and target market
- State material and manufactoring processes
- Redesign lid
- Incorporate foil seal for freshness
- List advantages of the product on the posters

Disassemble - Toaster Oven

The Project was to disassemble an appliance and work out how improvements could be made.
The three areas we looked into were, how to increase durability, how to make reparable and upgradable, and finally how to improve dissassembly so that the parts can be reused and recycled.
The photos below show our progress.

 

The 11th Hour

 The 11^th hour (2007) is a documentary produced and narrated by Leonardo DiCaprio, directed by Leila and Nadia Conners. The film interviews many independent environmental experts about climate change, what the causes are, what can be done and why humans are so slow to react. An early quote from Stephen Schneider sets the scene, “As we destroy nature, we will be destroyed in the process.” Several of the experts state that the human brain is the key to our survival, stating that humans are the only species able to think of the future. 
The somewhat typical binary of human-vs-nature is an underlying rubric to the argument flow of the documentary narrative, subverting the arguments of economic rationalism with quantitative research attesting the finite nature of Earth's resources. Conners' argument asserts that change began with the industrial revolution and the lessening of sunlight to survive, going on to explore our dependency on fossil fuels and an increasing dependency on globalised mass farming. 
The documentary rings home with all the radical changes in climate such as the floods, droughts, extreme hurricanes, highest average temperatures on record. A worst-case scenario for the future as stated by Stephen Hawking is that earth could become like its sister planet Venus, where the temperature is 250˚C and it rains sulphuric acid.
The earth is being radically changed in a short period of time, and our appetite for consumer goods that rely heavily on natural resources continues to grow. We are essentially poisoning the planet. The argument is compounded with, typically for infotainment, one of hope. We have a chance to fix this. We need to reconnect with nature. We have existing technologies to create green buildings and to retro fit pre 1950’s buildings that could reduce our carbon footprint by 90%. We need to redesign design. We need to change the thinking of products from cradle to grave, to cradle to cradle. In nature there is no waste. We need to have a passion for where you live.  
Documentaries like this serve perhaps as the exact type of passive project, ambitious of some mythical kind of proto-stimulation in the field that they criticise in their argument - basically a lot of rich people made this as a feel good product - placing the importance of human agency squarely on a working class who will probably never see this documentary.  

99.9999% of species are extinct. Humans can become part of that statistic. The earth will survive. Will we still be on it?

Image 
Video Link 

Video Reflection - Packaging

 

After viewing the video series of both ‘How It’s Made: Packaging’ and ‘Giving Packaging a New Life’ the viewer is left with a solid understanding of how different types of packaging is made, and the recycling processes at the end of life.

The videos give a detailed view of the processes required for packaging from start to finish, including the recycling processes such as sorting and breaking down the packaging.

The aluminium packaging tubes was an informative video to watch. As I had little knowledge of how they were made before this video. It was interesting to learn that the tubes are made from a single disc of aluminium that was punched from a flat sheet. The disc is then fed into a press for impact extrusion, which creates the tube shape. The scrap aluminium from the sheet gets recycled into a new aluminium sheet, ready for the next set of discs to be punched. This process was relatively the same for the aluminium drink containers.

I was fascinated to learn how easily recyclable tetrapaks are. As they are made from laminated paper, plastic and foil I had assumed the process to recycle them would be difficult. Upon watching the video I learned it was a simple process of chopping the material up and adding water so the paper would swell and separate from the foil and plastic layers.

One thing I had always wondered was how recycling was separated, as at home, there is only one bin that all recyclable material is put in to. That question was answered in the final video for ‘Giving Packaging a New Life’. Thanks to relatively new combined recycling plants, this process is now easier and can save up to 50% of associated costs compared to separate recycling plants. The collected recyclables are sent to a combined recycling plant where they are emptied onto big conveyer belts. From these belts the contents are separated. Air blowers separate the lightweight plastic films into one section. Magnets are used to collect the metals and sieves remove the paper products. Infra red systems are used to detect composite packaging, such as tetrapaks, and channel a localised blast of air to separate these. Once the differing materials are separated they can be recycled accordingly.

It is important for designers to understand these processes as this knowledge enables the designer to consider the impact of the product they are designing, and whether there is a less environmentally intrusive way of bringing a new product to life.

This knowledge also creates certain dilemmas in the designing process. Whether the designer will choose glass packaging as this can be made from up to 90% recycled material saving energy in production and reducing the need for virgin material taken from natural resources. However, this type of packaging is heavy which leads to increased transport costs and carries the risk of the glass breaking leaving dangerous shards.

Image link 

How It's Made Videos 

Giving Packaging a New Life Videos 

Bin

Tea?

Fridge of the Future

A lesson in what can go wrong.........

Peer comments

Charmaine Chen
Stan Darmawan
Jen Jun Zhu
Fiona Lee
Kiran Kashyap