Skip to main content

Business information leak - Corporate information

Need

Protection of sensitive corporate information from unauthorized access

Context

  • Usage of Go 1.16 for developing high-performance and concurrent applications
  • Usage of gin-gonic/gin for building web applications and APIs in Go
  • Usage of net/http for creating HTTP servers in a Node.js application

Description

Non compliant code

package main

import (
"github.com/gin-gonic/gin"
"net/http"
)

type Employee struct {
Name string `json:"name"`
Role string `json:"role"`
Email string `json:"email"`
}

var Employees = []Employee{
{"John Doe", "Manager", "[email protected]"},
{"Jane Doe", "Engineer", "[email protected]"},
}

func main() {
r := gin.Default()

r.GET("/employees", func(c *gin.Context) {
c.JSON(http.StatusOK, Employees)
})

r.Run()
}

The above code is an example of a Go backend application that uses the Gin framework. This application has a GET endpoint /employees that returns a list of employees in the company. Each employee object contains the name, role, and email of an employee.

The vulnerability in this code is that it exposes sensitive business information, such as the roles and contact information of employees. This information is accessible to anyone who can send a GET request to the /employees endpoint, which is a serious security risk. This can lead to business information leaks and potentially be used for malicious activities such as phishing attacks.

In this case, the sensitive information is hardcoded into the application, but in a real-world scenario, it would likely be loaded from a database or another data source. Regardless of the data source, it's important that sensitive information is not exposed through the application's endpoints without proper authorization and access control.

Steps

  • Implement authentication and authorization mechanisms to restrict access to sensitive information.
  • Create a separate endpoint or API for retrieving employee information, and ensure that it is only accessible to authorized users.
  • Use proper access control measures to ensure that only authorized users can access the employee information.
  • Encrypt sensitive employee information to protect it from unauthorized access.
  • Regularly review and update the access control policies to ensure they are effective and up to date.
  • Implement logging and monitoring mechanisms to detect and respond to any unauthorized access attempts.

Compliant code

package main

import (
"github.com/gin-gonic/gin"
"net/http"
"github.com/auth0/go-jwt-middleware"
"github.com/dgrijalva/jwt-go"
)

type Employee struct {
Name string `json:"name"`
Role string `json:"role"`
Email string `json:"email"`
}

var Employees = []Employee{
{"John Doe", "Manager", "[email protected]"},
{"Jane Doe", "Engineer", "[email protected]"},
}

var jwtMiddleware = jwtmiddleware.New(jwtmiddleware.Options{
ValidationKeyGetter: func(token *jwt.Token) (interface{}, error) {
return []byte("My Secret"), nil
},
SigningMethod: jwt.SigningMethodHS256,
})

func main() {
r := gin.Default()

r.Use(func(c *gin.Context) {
err := jwtMiddleware.CheckJWT(c.Writer, c.Request)

if err != nil {
c.Abort()
c.Writer.WriteHeader(http.StatusUnauthorized)
c.Writer.Write([]byte("Unauthorized"))
return
}
})

r.GET("/employees", func(c *gin.Context) {
c.JSON(http.StatusOK, Employees)
})

r.Run()
}

The updated code now includes a JWT middleware for authentication. This middleware checks the JWT token in the request header for all incoming requests. If the token is not present or invalid, it returns an "Unauthorized" response.

The JWT middleware uses a secret key ("My Secret" in this case) to validate the token. In a real-world application, this secret should be stored securely and not be hardcoded as it is in this example.

The r.Use function is a global middleware function in Gin. It applies the middleware to all the routes in the application. In this case, it applies the JWT middleware to all routes, thus protecting all endpoints, including the "/employees" endpoint.

This way, only authorized users (those who send a valid JWT token in the request header) can access the employee information. Unauthorized users will receive a "401 Unauthorized" response.

Please note that this code does not include the part where the JWT tokens are issued to users. In a real-world application, you would have a login or a similar endpoint that authenticates users and issues them a JWT token. Users would then use this token to access the protected routes.

References