Skip to main content

Business information leak - Analytics

Need

Protection of sensitive business information in analytics data

Context

  • Usage of Go 1.16 for building efficient and scalable applications
  • Usage of gin-gonic/gin for building web applications in Go
  • Usage of gin-swagger for generating Swagger documentation in a Gin web framework
  • Usage of swaggerFiles from github.com/swaggo/gin-swagger for serving Swagger UI files in a Gin framework application

Description

Non compliant code

package main

import (
"github.com/gin-gonic/gin"
"github.com/swaggo/gin-swagger"
"github.com/swaggo/gin-swagger/swaggerFiles"
)

var APIKey = "your-api-key"

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

// Exposed Swagger URL
url := ginSwagger.URL("http://localhost:8080/swagger/doc.json")
r.GET("/swagger/*any", ginSwagger.WrapHandler(swaggerFiles.Handler, url))

r.Run()
}

This code is a simple demonstration of a Go backend application using the Gin framework and Swagger for API documentation. The application has a single endpoint /swagger/*any which serves the Swagger UI for API documentation.

The vulnerability lies in the exposure of the Swagger URL along with the API key. The API key is hardcoded into the application, which is a bad practice as it can be easily discovered and exploited. Furthermore, the Swagger documentation may reveal sensitive information about the API, such as the structure of requests and responses, the endpoints available, and the data models used. This information can be used by an attacker to understand the underlying implementation of the application and identify potential points of attack.

An attacker could potentially access the exposed Swagger URL, use the provided API key to make requests to the API, and gain access to business insights from mobile app usage analytics.

The secure way to handle this would be to remove the API key from the code, store it securely (for example, in environment variables or a secure vault), and restrict access to the Swagger documentation to authorized users only. This would prevent unauthorized access to the API and the leakage of sensitive business information.

Steps

  • Remove the exposed Swagger URL from the code.
  • Implement authentication and authorization mechanisms to restrict access to the Swagger documentation.
  • Consider using environment variables or a secure configuration file to store the API key instead of hardcoding it in the code.
  • Ensure that the Swagger documentation is only accessible to authorized users or within a secure network.
  • Regularly review and update the Swagger documentation to remove any sensitive business information.

Compliant code

package main

import (
"github.com/gin-gonic/gin"
"github.com/swaggo/gin-swagger"
"github.com/swaggo/gin-swagger/swaggerFiles"
"os"
)

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

// Removed exposed Swagger URL
// url := ginSwagger.URL("http://localhost:8080/swagger/doc.json")
// r.GET("/swagger/*any", ginSwagger.WrapHandler(swaggerFiles.Handler, url))

// Implement authentication and authorization
r.Use(AuthMiddleware())

r.Run()
}

// AuthMiddleware is a sample middleware for authentication and authorization
func AuthMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
// Implement your authentication and authorization logic here
// For example, you can check the request headers for a valid token
// If the token is invalid, you can call c.Abort() to stop the request
// If the token is valid, you can call c.Next() to proceed with the request

// Here is a dummy implementation:
token := c.GetHeader("Authorization")
if token != os.Getenv("API_KEY") {
c.AbortWithStatusJSON(401, gin.H{"error": "Unauthorized"})
return
}

c.Next()
}
}

The updated code removes the exposed Swagger URL, which was a potential security vulnerability. Instead of exposing the Swagger documentation to the public, it is now protected by a middleware function AuthMiddleware(). This function checks the Authorization header of each request. If the header does not contain the correct API key, the request is aborted with a 401 Unauthorized status. The API key is now stored in an environment variable, which is a safer practice than hardcoding it in the code.

The AuthMiddleware() function is a placeholder for your actual authentication and authorization logic. You should replace it with your own logic to verify the identity and permissions of the user making the request.

By implementing these changes, the Swagger documentation is now only accessible to authorized users, which reduces the risk of business information leakage.

References