HTTPS is more secure than HTTP because it uses encryption protocols like TLS (Transport Layer Security) or SSL (Secure Sockets Layer) to encrypt the data transmitted between the client and the server. This ensures that data like passwords, credit card information, and personal details remain confidential and safe from interception by malicious actors during transmission.
The TCP handshake establishes a reliable connection between a client and a server. It involves a three-step process: SYN (synchronize), SYN-ACK (synchronize-acknowledge), and ACK (acknowledge). Once this connection is established, the TLS handshake begins to secure the connection. TLS handshake involves certificate exchange and verification, agreement on encryption algorithms, and the creation of session keys. This ensures that data transmitted over the established TCP connection is encrypted and secure.
SQL injection is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. It generally involves inserting malicious SQL code into an input field, which is then executed by the server, leading to potential unauthorized access or data manipulation.
Our current Spring implementation utilizes Object-Relational Mapping (ORM), which typically employs parameterized statements for security. However, it still allows string concatenation for complex queries, potentially creating vulnerabilities.
There are other ways to secure applications against SQL attacks, such as client-side validation, but these should be researched further for a comprehensive understanding.
<script>
var userData = document.URL.substring(document.URL.indexOf("userData=") + 9);
document.getElementById("userData").innerHTML = decodeURIComponent(userData);
</script>
## Challenge 1
Went to inspect element, and saw that the method that was used for Red was "GET" and for Blue was "POST". We can do more research on these, as they are different HTTP requests. Looking through the list, we see that the second request method is "HEAD" which seems quite familiar. If we look back at the challenge title "Get aHead", the word Head stands out, probably referring to the HTTP Request method "HEAD". Then I though of a way of handling these requests so I went to post man and went to head and there it was.
## Challenge 2
First I typed in snickerdoodle in the box and then went to inspect element. Then I thought where can I inspect the cookies and so I went to inspect element and application and then clicked on the cookie. I kept adding 1 to the value and reloading and it gave the flag at value of 18
## Challenge 3
Went to inspect element and saw a file path and clicked it and looked through it. Then I looked through it for a while and was determined and knew it was in there and so then I found a file path and put in the link of the file path. ./JIFxzHyW8W. Then it gave me a file to download and at the bottom, was the flag picoCTF{51e513c498950a515b1aab5e941b2615}
## Challenge 4
Upon accessing the link, we encounter a rather simple website. The challenge's title hints at searching for a robots.txt file. This file is essentially a text document used to prevent web robots from operating automatically. Interestingly, a frequent error is the placement of confidential information in files mentioned in the robots.txt file. When we look for this file by going to http://jupiter.challenges.picoctf.org:36474/robot.txt and we get this:
Then we see this /477ce.html and put it in the link now and we get the flag:
## Challenge 5
Tipped us off that code may need inspection so I inspected and looked through it and found a part of the code.
Then I looked through another link I found in the inspect element, the mycss.css and found the second third of the flag:
Then I saw another one, a js file and opened in new tab and found the last part of the flag:
# 5 Challenges Completed!
# Second Hacks
# Hacks 3: Show and explain how CORS has been used in your previous projects
In a project I worked on last trimester, I utilized Cross-Origin Resource Sharing (CORS) to integrate a cancer data API with a Java-based backend for a cancer data website. This implementation was crucial to allow the frontend, hosted on a different domain, to interact with our backend services securely.
To enable CORS in the Spring Boot application, I used the WebMvcConfigurer interface. This involved creating a configuration class, CorsConfig, where I defined a bean that overrode the addCorsMappings method. Here's a snippet of the code I wrote:
```java
package com.nighthawk.spring_portfolio;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;
@Configuration
public class CorsConfig {
@Bean
public WebMvcConfigurer corsConfigurer() {
return new WebMvcConfigurer() {
@Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/**")
.allowedOrigins("*")
.allowedMethods("GET", "POST", "PUT", "DELETE")
.allowedHeaders("*")
.allowCredentials(true);
}
};
}
}
In this configuration, I specified that all endpoints (/*) should allow requests from any origin (allowedOrigins(“”)). This was particularly important because our frontend and backend were hosted on different domains. By allowing methods like GET, POST, PUT, and DELETE, I ensured that the frontend could perform all necessary operations on the backend.
The allowedHeaders(“*”) setting was essential for handling the HTTP headers that the frontend might send. This flexibility was vital as different parts of the application required various types of headers for authentication and content-type specifications.
Lastly, the allowCredentials(true) part was critical to handle sessions and cookies securely, especially since our application dealt with sensitive medical data.
By implementing CORS this way, I resolved the cross-origin issues that initially prevented the frontend from effectively communicating with the backend. This setup was instrumental in the smooth functioning of our cancer data website, enabling seamless data retrieval and manipulation through the Java API.
[slimstat] shortcode in the plugin had an insecure implementation, failing to adequately sanitize the ‘w’ attribute, leading to database queries and outputs without proper escaping.