Tag Archives: CS-343

Blog Post #4

Building Secure Web Applications

Title: Building Secure Web Applications

Blog Entry:

This week, I developed the issue of web application security- a growing serious field in the software development. With the growing interconnectedness of applications and the increasingly data-driven nature of the application development process, the importance of user information and system integrity is equal to the one of the functionality or performance. The subject is related to the course goals related to the design of systems, software quality, and secure coding practices.

During my research, I paid attention to the general weaknesses that programmers have to deal with, including cross-site scripting (XSS), SQL, and insecure authentication systems. Such weaknesses are usually brought about by a failure to look into security requirements at the initial design phase. As an illustration, the inability to check input correctly may enable attackers to inject bad codes or access classified information. Security by design is based on the idea that protection must be implemented at each stage of development instead of viewing security as an a posteriori.

I also reviewed the industry best practice of enhancing application security. The common attacks are prevented with the help of techniques like the parameterized queries, the enforcement of the HTTPS protocol and encryption of the sensitive data and the use of the secure authentication frameworks. Periodical code inspection, automated testing, and standard compliance, such as the Top Ten guide by the OWASP, make code developers responsible to the creation of more robust systems. I was also informed that a healthy security culture in a development team, wherein the whole team takes the responsibility of securing the data of its users, is as valuable as any technical measures.

This subject matter was echoed in our discussions in the classroom on software reliability and maintainability. Secure code is just like clean code in that the code will be used over a long period. I was intrigued by the fact that the same principles of design made it more secure such as the principles of clarity, simplicity, and modularity. A well-organized system, which is simple to audit, has fewer chances of concealing undetectable weaknesses.

Reflection:

This study has made me understand that the need to develop applications that are secure is not just a technical one, but also a moral obligation. The developers should be able to consider the risks and the safety of users in advance. Security should not be at the expense of usability but rather it should complement usability to produce software that the user can trust. This attitude has motivated me to follow safe coding practices early in my work which includes validating inputs, data handling and sound frameworks.

In general, this discovery broadened my perspective on contemporary software design to include aspects of performance and functionality. Security is a key component of quality software engineering like never before. With these principles combined, I am more confident that I will be able to create applications that are efficient and scalable, besides being user-safe in the ever-digitized world.

Next Steps:

Next time, I will test some security orientated tools in the form of penetration testing systems and auto vulnerability scanners. I will also consider reading more on OWASP guidelines as a way of enhancing my knowledge on emerging threats and mitigation controls.

, , , ,
, , , ,
, , , , 



From the blog CS@Worcester – Site Title by Yousef Hassan and used with permission of the author. All other rights reserved by the author.
					

		
		
	


	

				

			
						

				Blog Post #4
			

								


				

			
Building Secure Web Applications


Title: Building Secure Web Applications


Blog Entry:


This week, I developed the issue of web application security- a growing serious field in the software development. With the growing interconnectedness of applications and the increasingly data-driven nature of the application development process, the importance of user information and system integrity is equal to the one of the functionality or performance. The subject is related to the course goals related to the design of systems, software quality, and secure coding practices.


During my research, I paid attention to the general weaknesses that programmers have to deal with, including cross-site scripting (XSS), SQL, and insecure authentication systems. Such weaknesses are usually brought about by a failure to look into security requirements at the initial design phase. As an illustration, the inability to check input correctly may enable attackers to inject bad codes or access classified information. Security by design is based on the idea that protection must be implemented at each stage of development instead of viewing security as an a posteriori.


I also reviewed the industry best practice of enhancing application security. The common attacks are prevented with the help of techniques like the parameterized queries, the enforcement of the HTTPS protocol and encryption of the sensitive data and the use of the secure authentication frameworks. Periodical code inspection, automated testing, and standard compliance, such as the Top Ten guide by the OWASP, make code developers responsible to the creation of more robust systems. I was also informed that a healthy security culture in a development team, wherein the whole team takes the responsibility of securing the data of its users, is as valuable as any technical measures.


This subject matter was echoed in our discussions in the classroom on software reliability and maintainability. Secure code is just like clean code in that the code will be used over a long period. I was intrigued by the fact that the same principles of design made it more secure such as the principles of clarity, simplicity, and modularity. A well-organized system, which is simple to audit, has fewer chances of concealing undetectable weaknesses.


Reflection:


This study has made me understand that the need to develop applications that are secure is not just a technical one, but also a moral obligation. The developers should be able to consider the risks and the safety of users in advance. Security should not be at the expense of usability but rather it should complement usability to produce software that the user can trust. This attitude has motivated me to follow safe coding practices early in my work which includes validating inputs, data handling and sound frameworks.


In general, this discovery broadened my perspective on contemporary software design to include aspects of performance and functionality. Security is a key component of quality software engineering like never before. With these principles combined, I am more confident that I will be able to create applications that are efficient and scalable, besides being user-safe in the ever-digitized world.


Next Steps:


Next time, I will test some security orientated tools in the form of penetration testing systems and auto vulnerability scanners. I will also consider reading more on OWASP guidelines as a way of enhancing my knowledge on emerging threats and mitigation controls.


, , , , 


, , , , 


, , , , 





From the blog CS@Worcester – Site Title by Yousef Hassan and used with permission of the author. All other rights reserved by the author.
					

		
		
	


	

				

			
						

				The art of REST API design
			

								


				

			
Something I have personally never worked on as a developer is REST API. AWS is a piloting force in the sphere of web development so there was no better place to read up on this subject than there. Going through you can really see why REST API is so vital to the modern web.


An overview of REST API design principles, methods, and benefits, illustrating key concepts for web development.


What is an API?


API stands for Application Programming Interface, this defines the rules you must follow to communicate with other software systems. 


API is a gateway betweek:


    

  • Clients: Users who want to access information from the web
    • 

  • Resources: The information that different applications provide to their clients.
    • 



What is REST?


REST stands for Representational State Transfer, this is a software architecture that imposes conditions on how an API should work. It was originally created as a guideline to manage communication on complex networks. As a result one architecture developers can use is RESTful API.


Here are some of the principles of the REST architectural style:


    

  • Uniform interface

      

    • Indicates the server transfers information in a standard format
      • 

    • 4 architectural contraints:

        

      • Requests should identify resources
        • 

      • Clients have enough info in the resource representation to modify or delete the resource if wanted
        • 

      • Clients receive info about how to process the representation further
        • 

      • Clients receive info about all other related resources they need to complete a task.
        • 

      

      • 

    

    • 

  • Statelessness

      

    • A communication method in which the server completes every client request independently of all previous requests
      • 

    

    • 

  • Layered System

      

    • Client can connect to other authorized intermediaries between the client & server, and it will still receive responses between the server
      • 

    

    • 

  • Cache-ability

      

    • Able to store some responses on the client or on an intermediary to improve response time
      • 

    

    • 

  • Code on demand

      

    • Servers can temporarily extend or customize client functionality by transferring programming code to the client.
      • 

    

    • 



Benefits to REST API:


Here are the few of the benefits AWS includes:


    

  • Scalability
    • 

  • Flexibility
    • 

  • Independence
    • 



How it works:


The basic functions are similar to browsing the internet, here are the general steps towards any REST API call:


    

  1. The client sends a request to the server
    2. 

  2. The server authenticates the client and confirms permissions to make request
    3. 

  3. The server receives request and processes it
    4. 

  4. The server returns a response to the client.
    5. 



The client request contains these main components:


    

  • Unique resource identifier
    • 

  • Method

      

    • GET

        

      • Access resources at URL
        • 

      

      • 

    • POST

        

      • Send data to server
        • 

      

      • 

    • PUT

        

      • Update existing resources on the server
        • 

      

      • 

    • DELETE

        

      • Request to remove resource
        • 

      

      • 

    

    • 

  • HTTP headers

      

    • Data
      • 

    • Parameters

        

      • Path: Specifies URL details
        • 

      • Query: Requests more info about resource
        • 

      • Cookie: Provides authentication
        • 

      

      • 

    

    • 



Final Thoughts:


My understanding of REST APIs was very limited but leave it to the best in the business to have all the information necessary to learn. I definitely think it would take time to implement nonetheless but having this basic understanding is important in the end. If you want to learn more yourself visit this page on AWS.


, , 



From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.
					

		
		
	


	

				

			
						

				CS343-01: Third Quarter Blog
			

								


				

			
Software Constr – Blog Three


APIs are something we come across a lot, especially the openapi.yaml file we look at for the Microservices Activities in class. So, I wanted to make a note for myself on what APIs are, the benefits, and the different types.


Firstly, what is an API? API stands for Application Programming Interface and it’s a mechanism that helps two software components communicate by the use of definitions and protocols. “For example, the weather bureau’s software system contains daily weather data. The weather app on your phone “talks” to this system via APIs and shows you daily weather updates on your phone.” And there are four different ways an API works: SOAP, RPC, Websocket, and REST.


The SOAP API is short for Simple Object Access Protocol API and it works with the client and server exchanging messages and other the use of XML. Remote Procedure Calls, RPC, APIs has the client complete a procedure on the server in which the said server would send back an output. Websocket APIs use JSON objects to pass the data being used and supports a two-way communication between the client apps and the server.


REST API is one we had just worked with in class and had homework on. It’s the most popular since it’s flexible and has the client send a request as data to the server which starts to use internal functions to return outputs back to the client. REST stands for Representational State Transfer that defines functions such as GET, PUT, DELETE, etc., all of which we have seen in the openapi.yaml file.


The REST API has four main benefits: integration, innovation, expansion, and ease of maintenance. Integration is used to increase development speed since the functionalities won’t have to be made from scratch because of the fact that APIs are used to integrate new applications with existing software systems.


Innovation is where industries can change with new arrivals of apps entirely since they can make changes without having to rewrite the entire code at the API level. “Businesses need to respond quickly and support the rapid deployment of innovative services.”


Expansion is something where it’s a unique chance for businesses to meet the needs of their customers across so many different platforms. “For example, maps API allows map information integration via websites, Android,iOS, etc. Any business can give similar access to their internal databases by using free or paid APIs.”


And finally, ease of maintenance. REST APIs act as a sort of gateway between systems. They each make changes internally so that the API isn’t impacted and in response? “Any future code changes by one party do not impact the other party.”


Source: https://aws.amazon.com/what-is/api/


, , 



From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.
					

		
		
	


	

				

			
						

				Refactoring your program
			

								


				

			
Sometimes when a program undergoes consistent updates it can get messy, in cases like this it can be useful to refactor it. I’ve had a few experienced cleaning a program however I have never refactored an entire program. The developers over at refactoring guru luckily have a website dedicated to this subject.


An illustrated depiction of a programming refactoring process, highlighting the importance of clean code.


Purpose for refactoring


When you refactor a program you are fighting something they call technical debt and create clean code. With clean code comes a few benefits including:


    

  • Obvious for other programmers
    • 

  • Doesn’t contain duplicate code
    • 

  • Minimal number of classes and other moving parts
    • 

  • Passing of all tests
    • 

  • Easier and cheaper to maintain
    • 



What is technical debt?


“Technical debt” as a metaphor was originally suggested by Ward Cunningham using bank loans as an example.


You can make purchases faster If you get a loan from a bank however now on top of principal you have interest. and with time you can rack up so much interest that the amount of interest exceeds your total income, making full repayment impossible.


The same concept can be applied to code. Speeding up without testing new features will gradually slow your progress.


Some causes of technical debt include:


    

  • Business pressure
    • 

  • Lack of understanding the consequence
    • 

  • Failing to combat the strict coherence of components
    • 

  • Lack of tests, documentation, communication.
    • 

  • Long-term simultaneous development in several branches
    • 

  • Delayed refactoring
    • 

  • Incompetence
    • 



So when should one refactor?


Refactoring guru comes up with a few instances on when to refactor.


    

  • Rule of three:

      

    • When doing something for the first time, just get it done.
      • 

    • When doing something similar for the second time, cringe at having to repeat but do the same thing anyway.
      • 

    • When doing something for the third time, start refactoring.
      • 

    

    • 

  • Adding a feature:

      

    • If you have to deal with someone else’s dirty code, try refactoring it first; Easier for future features.
      • 

    

    • 

  • Fixing a bug:

      

    • Clean the code and errors will discover themselves
      • 

    

    • 

  • Code reviews:

      

    • Last chance to tidy up the code
      • 

    • Best to perform these reviews in pair with an author
      • 

    

    • 



We know when, but how?


Refactoring is done via a series of small changes, each making the existing code slightly better while leaving the program in working order.


Here is a checklist on refactoring done the right way:


    

  • The code is cleaner
    • 

  • There should not be new functionality
    • 

  • All existing tests pass
    • 



Final Thoughts:


Overall, I found this website on refactoring to be really informative and would recommend refactoring guru as a starting point. The most important thing that I got out of this is that developers should always try to write clean code or clean code as its undergoing development. Unfortunately sometimes software development can be very time containing and its not always possible which is why refactoring is important.


, , 



From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.
					

		
		
	


	

				

			
						

				CS343-01: Week (Quarter) Two
			

								


				

			
Software Constr – Blog Two


In class, we learned two acronyms. DRY which was Don’t Repeat Yourself and YAGNI which meant You Ain’t Gonna Need It. So, I was curious as to what others we had and why we had them in the first place.


When researching on why acronyms like DRY and YAGNI are important, I came across that “in the ever-evolving world of software development, clean, maintainable code isn’t a luxury — it’s a survival skill. As systems grow and teams scale, codebases can quickly become tangled, brittle, and expensive to change.” The acronyms are principles that help us write code that are sustainable and that even though they’re easy to understand, they’re powerful when applied.


Alongside DRY and YAGNI, there’s also KISS (Keep It Simple, Stupid). The KISS principle “encourages developers to avoid unnecessary complexity. Whether you’re writing a function or designing an entire system, simplicity is often the best strategy.” This is important since if there’s a lot involved in the project, then there’s a lot more risk of bugs when can result in the needless complexity, rigidity, etc. that we learned in class.


This principle was actually created by a systems engineer named Kelly Johnson who was working for Lockheed Skunk Works which was the team that developed the SR-71 Blackbird (“a retired long-range, high-altitude, Mach 3+ strategic reconnaissance aircraft,” according to Wikipedia). “His idea was simple: systems should be so straightforward that even someone with basic training could repair them under stressful conditions — like in combat. This philosophy translated beautifully into software, where complexity is often the enemy of reliability.”


I learned that DRY “was introduced by Andy Hunt and Dave Thomas in their 1999 book The Pragmatic Programmer. Their definition was concise but profound: ‘Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.’” It helps reduce redundancy and speed up development in a project.


I learned that YAGNI worked as “a reminder to avoid building features or abstractions that aren’t immediately required” because of the encouragement it gives to “developers to resist the urge to ‘future-proof’ code based on assumptions about needs that may never materialize.” I also learned that YAGNI came from a thing called Extreme Programming (XP) and was popularized by Ron Jeffries, one of the original Agile Manifesto signatories. It became a core tenet of XP: ‘Always implement things when you actually need them, never when you just foresee that you need them.’” It helped prevent overthinking in engineering and keep the development focused on solving the problems of today rather than in the future.


Source: https://levelup.gitconnected.com/software-architecture-explaining-kiss-dry-yagni-with-practical-examples-in-typescript-9bf23c484816 


, 



From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.
					

		
		
	


	

				

			
						

				Principle of Least Knowledge (AKA Law of Demeter)
			

								


				

			
Hello everyone, today I will be talking about the Principle of Least Knowledge (AKA Law of Demeter). When first looking into this topic I was unsure of exactly what this was and how it would be applied to programming. When doing my research I found the Khouri College of Computer Sciences at North Eastern University had a page dedicated to this topic, where this law was first introduced.


General Formulation


Illustration of the Law of Demeter, highlighting the principle of limiting interactions between objects.


The LoD is essentially a simple style rule for designing object oriented systems.


“Only talk to your immediate friends” is the motto. 


Professor Leiberherr, the author, states a formulation of “Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.” Its main motivation is to control information overload thus helping memory management as each item is closely related.


You can informally summarize the Law with these three formulations:


    

  • Each method can only send messages to a limited set of objects, namely to the argument objects and to the immediate subparts of the class to which the method is attached.
    • 

  • Each method is “dependent” on a limited set of objects (organize dependencies)
    • 

  • Each method “collaborates” with a limited set of objects (organize collaborations)
    • 



To formulate the Law we can choose from the following independent possibilities:


    

  • Object/Class

      

    • Class formulation is intended to be compile-time
      • 

    • Object formulation is intended to be followed conceptually
      • 

    

    • 

  • Messages/Generic functions/Methods
    • 

  • Weak/Strong

      

    • If we interpret it as all instance variables, including the inherited ones, we get the weak form of the Law. If we exclude the inherited instance variables, we get the strong form of the Law.
      • 

    

    • 



Benefits


In a paper written by Leiberherr, there are a couple facts stated for the benefits:


    

  • If the weak or strong LoD is followed and if class A’s protocol is renamed, then at most the preferred client methods of A and A’s subclasses require modification.
    • 

  • If the weak or strong LoD is followed and if the protocol of class A changes, then only preferred client methods of A and its subclasses need to be modified and only methods in the set of potential preferred clients of A and its subclasses need to be added
    • 

  • There’s even more benefits highlighted in the paper pertaining to limiting information overload.
    • 



Final Thoughts:


Prior to this webpage I knew nothing about this law/principle, however I now understand that it is a fairly useful rule or its respective use case. The law teaches you a way to program Classes, Inheritance, Abstraction, and a few other techniques. Infact There is so much more depth to this that I cant even fully fit it into this blog post. I would highly recommend you check out this page as It contains all the information you need along with sources to learn this.


, , 



From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.
					

		
		
	


	

				

			
						

				How to become a SOLID software developer.
			

								


				

			
By Petraq Mele


Hello again to those reading this blog, this time I want to talk about an extremely topic relevant in the programming atmosphere, that being a concept known as SOLID. I managed to find a great section written by Manoj Phandis on these principles.


SOLID is an acronym of five OOP design principles designed to help make it more understandable, flexible, and maintainable.


What are the main 5 design principles?


SINGLE RESPONSIBILITY PRINCIPLE: This principle states a class should have one, and only one, reason to change. Lets take an Animal class example, as opposed to the animal class having a sound and feed parameter, separate those responsibilities into separate classes.


Some benefits include:


    

  • more readable, that is easier to understand
    • 

  • less error prone
    • 

  • more robust
    • 

  • better testable
    • 

  • better maintainable and extendable
    • 

  • maximizes the cohesion of classes.
    • 



OPEN CLOSED PRINCIPLE: “Open for extension” means the behavior of a module can be extended. “Closed for extension” means when we are adding/extending a modules behavior it should not result in changes to a modules source or binary code.


Demonstration of the Open/Closed Principle in object-oriented programming.


 An example Manoj gives is a credit card company wanting to introduce a new preferred credit card product with double reward points. Instead of using conditionals, you create an extension via implementation inheritance or interface abstraction. 


LISKOV SUBSTITUTION PRINCIPLE: LSP states functions that use references to base classes must be able to use objects of the derived class without knowing it. For LSP compliance we need to follow some rules that can be categorized into 2 groups:


    

  • Contract rules

      

    • Preconditions cannot be strengthened or weakened in a subtype
      • 

    • Invariants must be maintained
      • 

    

    • 

  • Variance rules

      

    • There must be contra-variance of the method argument in the subtype & be covariance of the return type in the subtype
      • 

    • No new exceptions can be thrown by the subtype unless they are part of the existing exception hierarchy.
      • 

    

    • 



INTERFACE SEGREGATION PRINCIPLE: Clients should not be forced to depend on methods they do not use. Interface segregation violations result in classes depending on things they don’t need & an increase of coupling and reduced flexibility/maintainability.


Tips to follow:


    

  • Prefer small, cohesive interfaces to “fat” interfaces
    • 

  • Creating smaller interfaces with just what we need
    • 

  • Have the fat interface implement your new interface.
    • 

  • Dependency of one class to another should depend on the smallest possible interface.
    • 



DEPENDENCY INVERSION PRINCIPLE: This principle has two parts. The first part says high-level modules should not depend on low-level modules. Both should depend on abstractions. The second part says Abstractions should not depend on details. Details should depend on abstractions.


Part one example:










Part two example:






Final thoughts:


Overall these principles are very useful when it comes to  object-oriented software development. I learned quite a good amount and I want to thank Manoj Phandis for their amazing outline of the SOLID principles, I would advise you to check them out in his website incase you’re interested in learning more.


, , 



From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.
					

		
		
	


	

				

			
						

				CS343-01: Week One Blog
			

								


				

			
Software Constr – Week One


For week one’s blog, I read the article I first found, Software Architecture Recommendations By Mark Richards. I wanted to start off with something I’ve found first before potentially either diving into more research for videos and articles or maybe even going through what my classmates have found for inspiration.


In Software Architecture Recommendations By Mark Richards, it features a software architect named Mark Richards who covers his definition of software architecture along with the key soft skills and responsibilities of an architect. There are two aspects of software architecture in his vision, as structure and as process. “Within the structural aspect of software architecture there are 4 dimensions: architecture characteristics, architecture components, architecture styles, and architecture decisions.” He mentions how there are soft skills and techniques which include negotiation, facilitation, and leadership when it comes to the process aspect he sees in software architecture.


He says that negotiation is a required skill since “almost every decision you make as an architect will be challenged. Your decisions will be challenged by other architects who think they have a better approach than you do; your decisions will be challenged by business stakeholders because they think your decision takes too long to implement or is too expensive or is not aligned with the business goals; and finally, your decisions will be challenged by development teams who believe they have a better solution.” Which makes sense since if you want to do your job, people will think what they have to say is better, more efficient, etc. So you do have to understand the political climate– as the article says– and how to navigate it to get the views and decisions you made both approved and accepted.


Facilitation is another “soft skill” that Mark Richards thought of where the architects don’t only collaborate with development teams. He says that they should also collaborate with various business stakeholders to understand a number of things such as “business drivers, explain important architecture characteristics, describe architectural solutions, and so on.” Upon further research, I found that facilitation is a shift in the architect’s role from a central decision-maker to a facilitator who empowers the development team to make architectural decisions collaboratively, so it’s a tool to have to keep things on track.


And then there’s leadership. The architect in Mark Richards’ mind is responsible for leading and guiding the development team through implementations. “They are there as a guide, mentor, coach, and facilitator to make sure the team is on track and is running as smooth as a well-oiled machine, and to be there when the team needs clarification or has questions and concerns about the architecture.”


Reading this from his perspective and his opinions are an interesting way of learning his job as a software architect since he has the experience and he has learned from the mistakes he’s made. It’s an important thing to know that even though it’s his job, he’s always learning about ways to improve and for him to share this knowledge is something that’s valuable since you can take the advice and knowledge given and apply it to your own job.


Source: https://apiumhub.com/tech-blog-barcelona/software-architecture-recommendations-mark-richards/


, 



From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.
					

		
		
	


	

				

			
						

				CS343-01: Software Constr, Des & Archit
			

								


				

			
Software Constr – First Steps

This is the beginning of my documentation in my class CS-343 and phase two, part two, I suppose, for CS@Worcester with the work that I was able to accomplish, had trouble with, and solutions I found.It’s kind of like my last and now current blog, except new class equals new puzzles I’ll experience! I really hope to do well, even with quizzes or exams as a sort of weak spot for me.But hopefully, with enough reading and practicing, I’ll do well. I want to do well. I’m aiming to do well.


, 



From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.