Add Health Check Endpoint (#101)#108
Add Health Check Endpoint (#101)#108Divyansh Maheshwari (divyansh1010x) wants to merge 1 commit into
Conversation
Wiz Scan Summary
To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension. |
![wiz-55ccc8b716[bot]](https://avatars.githubusercontent.com/u/11163827?s=60&v=4){kind=small}
| o.Credentials = credentials.NewStaticCredentialsProvider( | ||
| *out.Credentials.AccessKeyId, | ||
| *out.Credentials.SecretAccessKey, | ||
| *out.Credentials.SessionToken, | ||
| ) |
There was a problem hiding this comment.
Hardcoded AWS Credentials in Go Application
More Details
Embedding static AWS credentials directly into a Go application using the credentials.NewStaticCredentialsProvider function poses a significant security risk. This practice exposes the AWS access keys and secret keys in plaintext within the application code, making them vulnerable to theft or misuse. If an attacker gains access to the application code or the compiled binary, they can extract the hardcoded credentials and potentially gain unauthorized access to AWS resources, leading to data breaches, financial losses, or other malicious activities.
Hardcoded credentials should never be used in production environments. Instead, applications should retrieve credentials securely from trusted sources, such as environment variables, secure key management services, or temporary credentials obtained through AWS Identity and Access Management (IAM) roles. Failing to properly manage and protect AWS credentials can lead to severe consequences, including data exfiltration, resource hijacking, and compliance violations.
| Attribute | Value |
|---|---|
| Impact |  |
| Likelihood | |
Remediation
Hardcoding AWS credentials into an application poses a significant security risk. If the application's code is compromised or accidentally exposed, the hardcoded credentials can be easily extracted and misused by attackers to gain unauthorized access to AWS resources, potentially leading to data breaches, financial losses, and other severe consequences.
To fix this issue securely, applications should retrieve AWS credentials from secure sources at runtime, such as environment variables, AWS credential files, or AWS credential providers. This approach ensures that credentials are not embedded in the application's code and can be easily rotated or revoked if needed.
Code examples
// VULNERABLE CODE - Hardcoded AWS credentials
import (
"github.com/aws/aws-sdk-go-v2/aws"
"github.com/aws/aws-sdk-go-v2/credentials"
)
creds := credentials.NewStaticCredentialsProvider(
"AKIAIOSFODNN7EXAMPLE",
"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"",
)// SECURE CODE - Using AWS credential provider
import (
"github.com/aws/aws-sdk-go-v2/config"
)
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
// Handle error
}
// AWS credentials are retrieved securely from the environment or other sourcesAdditional recommendations
- Follow the AWS best practices for managing AWS access keys and secret access keys.
- Implement least privilege access principles by granting only the necessary permissions to AWS resources.
- Regularly rotate AWS credentials and revoke unused or compromised credentials.
- Consider using temporary security credentials (AWS STS) for enhanced security and auditing capabilities.
- Adhere to relevant security standards and guidelines, such as the AWS Security Best Practices and the OWASP Application Security Verification Standard (ASVS).
Rule ID: WS-GO-00051
| o.Credentials = credentials.NewStaticCredentialsProvider( | ||
| *out.Credentials.AccessKeyId, | ||
| *out.Credentials.SecretAccessKey, | ||
| *out.Credentials.SessionToken, | ||
| ) |
There was a problem hiding this comment.
Hardcoded AWS Credentials in Go Application
More Details
Embedding static AWS credentials directly into a Go application using the credentials.NewStaticCredentialsProvider function poses a significant security risk. This practice exposes the AWS access keys and secret keys in plaintext within the application code, making them vulnerable to theft or misuse. If an attacker gains access to the application code or the compiled binary, they can extract the hardcoded credentials and potentially gain unauthorized access to AWS resources, leading to data breaches, financial losses, or other malicious activities.
Hardcoded credentials should never be used in production environments. Instead, applications should retrieve credentials securely from trusted sources, such as environment variables, secure key management services, or temporary credentials obtained through AWS Identity and Access Management (IAM) roles. Failing to properly manage and protect AWS credentials can lead to severe consequences, including data exfiltration, resource hijacking, and compliance violations.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
Hardcoding AWS credentials into an application poses a significant security risk. If the application's code is compromised or accidentally exposed, the hardcoded credentials can be easily extracted and misused by attackers to gain unauthorized access to AWS resources, potentially leading to data breaches, financial losses, and other severe consequences.
To fix this issue securely, applications should retrieve AWS credentials from secure sources at runtime, such as environment variables, AWS credential files, or AWS credential providers. This approach ensures that credentials are not embedded in the application's code and can be easily rotated or revoked if needed.
Code examples
// VULNERABLE CODE - Hardcoded AWS credentials
import (
"github.com/aws/aws-sdk-go-v2/aws"
"github.com/aws/aws-sdk-go-v2/credentials"
)
creds := credentials.NewStaticCredentialsProvider(
"AKIAIOSFODNN7EXAMPLE",
"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"",
)// SECURE CODE - Using AWS credential provider
import (
"github.com/aws/aws-sdk-go-v2/config"
)
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
// Handle error
}
// AWS credentials are retrieved securely from the environment or other sourcesAdditional recommendations
- Follow the AWS best practices for managing AWS access keys and secret access keys.
- Implement least privilege access principles by granting only the necessary permissions to AWS resources.
- Regularly rotate AWS credentials and revoke unused or compromised credentials.
- Consider using temporary security credentials (AWS STS) for enhanced security and auditing capabilities.
- Adhere to relevant security standards and guidelines, such as the AWS Security Best Practices and the OWASP Application Security Verification Standard (ASVS).
Rule ID: WS-GO-00051
| o.Credentials = credentials.NewStaticCredentialsProvider( | ||
| *out.Credentials.AccessKeyId, | ||
| *out.Credentials.SecretAccessKey, | ||
| *out.Credentials.SessionToken, | ||
| ) |
There was a problem hiding this comment.
Hardcoded AWS Credentials in Go Application
More Details
Embedding static AWS credentials directly into a Go application using the credentials.NewStaticCredentialsProvider function poses a significant security risk. This practice exposes the AWS access keys and secret keys in plaintext within the application code, making them vulnerable to theft or misuse. If an attacker gains access to the application code or the compiled binary, they can extract the hardcoded credentials and potentially gain unauthorized access to AWS resources, leading to data breaches, financial losses, or other malicious activities.
Hardcoded credentials should never be used in production environments. Instead, applications should retrieve credentials securely from trusted sources, such as environment variables, secure key management services, or temporary credentials obtained through AWS Identity and Access Management (IAM) roles. Failing to properly manage and protect AWS credentials can lead to severe consequences, including data exfiltration, resource hijacking, and compliance violations.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
Hardcoding AWS credentials into an application poses a significant security risk. If the application's code is compromised or accidentally exposed, the hardcoded credentials can be easily extracted and misused by attackers to gain unauthorized access to AWS resources, potentially leading to data breaches, financial losses, and other severe consequences.
To fix this issue securely, applications should retrieve AWS credentials from secure sources at runtime, such as environment variables, AWS credential files, or AWS credential providers. This approach ensures that credentials are not embedded in the application's code and can be easily rotated or revoked if needed.
Code examples
// VULNERABLE CODE - Hardcoded AWS credentials
import (
"github.com/aws/aws-sdk-go-v2/aws"
"github.com/aws/aws-sdk-go-v2/credentials"
)
creds := credentials.NewStaticCredentialsProvider(
"AKIAIOSFODNN7EXAMPLE",
"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"",
)// SECURE CODE - Using AWS credential provider
import (
"github.com/aws/aws-sdk-go-v2/config"
)
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
// Handle error
}
// AWS credentials are retrieved securely from the environment or other sourcesAdditional recommendations
- Follow the AWS best practices for managing AWS access keys and secret access keys.
- Implement least privilege access principles by granting only the necessary permissions to AWS resources.
- Regularly rotate AWS credentials and revoke unused or compromised credentials.
- Consider using temporary security credentials (AWS STS) for enhanced security and auditing capabilities.
- Adhere to relevant security standards and guidelines, such as the AWS Security Best Practices and the OWASP Application Security Verification Standard (ASVS).
Rule ID: WS-GO-00051
| } | ||
| defer db.Close() | ||
|
|
||
| rows, err := db.QueryContext(ctx, fmt.Sprintf("SHOW WAREHOUSES LIKE '%s'", clusterCtx.Warehouse)) |
There was a problem hiding this comment.
SQL Injection in Go Database Queries Using database/sql Package (CWE-89)
More Details
This rule detects potential SQL injection vulnerabilities in Go code that uses the database/sql package. SQL injection occurs when user-supplied data is improperly sanitized and included in SQL queries, allowing an attacker to execute arbitrary SQL commands.
| Attribute | Value |
|---|---|
| Impact |  |
| Likelihood |  |
Remediation
SQL injection is a technique where malicious SQL statements are inserted into application entry points, allowing attackers to view, modify or delete data in the application's database. This vulnerability can lead to unauthorized data access, data loss, and in some cases, complete system compromise.
To remediate this issue, use parameterized queries or prepared statements instead of string concatenation when constructing SQL queries. Parameterized queries separate the query logic from the user input, preventing the input from being interpreted as part of the SQL statement. This effectively eliminates the risk of SQL injection.
Code examples
// VULNERABLE CODE - User input is concatenated directly into the SQL query
query := "SELECT * FROM users WHERE name = '" + userName + "'"
rows, err := db.Query(query)// SECURE CODE - Using parameterized queries with placeholders
query := "SELECT * FROM users WHERE name = ?"
rows, err := db.Query(query, userName)Additional recommendations
- Follow the principle of least privilege and grant minimal database permissions to the application.
- Implement input validation and sanitization for all user-supplied data.
- Use the latest version of the database driver and keep it up-to-date with security patches.
- Adhere to the OWASP Top 10 and CWE guidelines for secure coding practices.
- Consider using an Object-Relational Mapping (ORM) library, which can help prevent SQL injection by automatically parameterizing queries.
- Implement centralized logging and monitoring to detect and respond to potential attacks.
Rule ID: WS-I013-GO-00041
2 participants
No description provided.