-
Notifications
You must be signed in to change notification settings - Fork 64
Tay #13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Tay #13
Changes from all commits
88fd6e5
b15aab8
cc81b6b
3932e7b
991fd4a
ba51984
8f66a68
c7e5aae
e5cd191
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,98 @@ | ||
--- | ||
trigger: model_decision | ||
description: Review this rule whenever a substantial amount of code has been edited or created | ||
--- | ||
|
||
# Security Best Practices for Windsurf Demo | ||
|
||
0. Ensure rate limiting is implemented. | ||
|
||
## General Security Guidelines | ||
|
||
1. **Keep Dependencies Updated** | ||
- Regularly update Flask, NumPy, and JavaScript dependencies | ||
- Use tools like `npm audit` and `pip-audit` to check for vulnerabilities | ||
- Pin dependencies to specific versions in requirements.txt and package.json | ||
|
||
2. **Input Validation** | ||
- Validate all user inputs on both client and server sides | ||
- Use parameterized queries for any database operations | ||
- Sanitize inputs to prevent XSS, SQL injection, and command injection | ||
|
||
3. **Authentication & Authorization** | ||
- Implement proper authentication for multiplayer features | ||
- Use secure session management with Flask-Session | ||
- Apply principle of least privilege for all operations | ||
|
||
4. **Secure Communications** | ||
- Use HTTPS for all communications in production | ||
- Implement proper CORS policies | ||
- Set secure and HttpOnly flags on cookies | ||
|
||
## Python-Specific Rules | ||
|
||
1. **Flask Configuration** | ||
- Never use `debug=True` in production | ||
- Set appropriate Content Security Policy headers | ||
- Disable Flask's development server in production; use gunicorn or uwsgi | ||
|
||
2. **Data Handling** | ||
- Validate and sanitize all JSON data received via API endpoints | ||
- Use Flask's built-in protection against CSRF attacks | ||
- Implement rate limiting on API endpoints | ||
|
||
3. **Error Handling** | ||
- Implement proper exception handling | ||
- Never expose stack traces to users | ||
- Log errors securely without exposing sensitive information | ||
|
||
## JavaScript-Specific Rules | ||
|
||
1. **Client-Side Security** | ||
- Use Content Security Policy to prevent XSS attacks | ||
- Sanitize any dynamic HTML content | ||
- Avoid using `eval()` or `innerHTML` | ||
|
||
2. **Game State Management** | ||
- Never trust client-side data for game logic | ||
- Implement server-side validation for all game state changes | ||
- Use secure random number generation for game mechanics | ||
|
||
3. **Third-Party Libraries** | ||
- Audit all third-party libraries before inclusion | ||
- Minimize use of external CDNs | ||
- Use Subresource Integrity (SRI) when loading external resources | ||
|
||
## Development Practices | ||
|
||
1. **Code Reviews** | ||
- Require security-focused code reviews | ||
- Use automated static analysis tools | ||
- Follow the "four eyes principle" for security-critical code | ||
|
||
2. **Testing** | ||
- Implement security-focused unit and integration tests | ||
- Perform regular security testing | ||
- Consider using tools like OWASP ZAP for vulnerability scanning | ||
|
||
3. **Deployment** | ||
- Use a proper CI/CD pipeline with security checks | ||
- Implement infrastructure as code with security best practices | ||
- Regularly backup and test restoration procedures | ||
|
||
## Specific Rules for this Application | ||
|
||
1. **Game State Protection** | ||
- Implement server-side validation for all player movements and actions | ||
- Use secure random number generation for food placement | ||
- Protect against cheating by validating game physics server-side | ||
|
||
2. **API Endpoints** | ||
- Implement rate limiting on `/update_player` and `/game_state` endpoints | ||
- Validate all incoming JSON data structure and values | ||
- Implement proper error handling for malformed requests | ||
|
||
3. **User Data** | ||
- Minimize collection of user data | ||
- Follow data protection regulations (GDPR, CCPA, etc.) | ||
- Implement proper data retention policies | ||
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -0,0 +1,13 @@ | ||||||
--- | ||||||
description: Apply security best practices to a specified file | ||||||
--- | ||||||
|
||||||
1. see if there are any security violations in whatever file is mentioned in the prompt by invoking the rule @security-best-practices | ||||||
|
||||||
2. check and see if there are already jira tickets related to this violation in TAY jira board | ||||||
|
||||||
IF not, create new tickets representing the violoation | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There's a typo in 'violoation' that should be corrected to 'violation'.
Suggested change
|
||||||
|
||||||
IF so, proceed with implementation of the fix | ||||||
|
||||||
3. Once implemention of the fix occurs update the jira ticket. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There's a typo in 'implemention' that should be corrected to 'implementation'.
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. /windsurf i think we should keep the incorrect spelling |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,13 @@ | ||
--- | ||
description: Create a new dbt data model | ||
--- | ||
|
||
0. Before creating a new model, ask me clarifying questions about what I am looking for with the model. | ||
|
||
1. Once I've added clarification, please create documentation for the model in the schema.yml file in the directory where we will eventually build the model. | ||
|
||
2. While you are adding documentation please add dbt tests that you predict will be important to the model. | ||
|
||
3. After I have reviewed the proposed documentation and tests in the schema.yml file, I'll likely give feedback. | ||
|
||
4. After I have approved the documented columns and tests in the schema.yml THEN Cascade you can go implement the new model. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,78 @@ | ||
|
||
function displayUserMessage(userInput) { | ||
document.getElementById('message').innerHTML = userInput; | ||
} | ||
|
||
|
||
function saveUserCredentials(username, password) { | ||
localStorage.setItem('user_credentials', JSON.stringify({ | ||
username: username, | ||
password: password | ||
})); | ||
} | ||
|
||
|
||
function fetchUserData(userId) { | ||
fetch(`/api/users/${userId}/data`) | ||
.then(response => response.json()) | ||
.then(data => { | ||
displayUserMessage(data.message); | ||
}); | ||
} | ||
|
||
|
||
function calculateUserInput(mathExpression) { | ||
return eval(mathExpression); | ||
} | ||
|
||
|
||
const API_KEY = "sk_test_12345abcdef"; | ||
|
||
|
||
function mergeObjects(target, source) { | ||
for (let key in source) { | ||
if (typeof source[key] === 'object') { | ||
target[key] = mergeObjects(target[key] || {}, source[key]); | ||
} else { | ||
target[key] = source[key]; | ||
} | ||
} | ||
return target; | ||
} | ||
|
||
|
||
function startDataProcessing() { | ||
let dataCache = []; | ||
|
||
document.addEventListener('data-received', function processData(event) { | ||
dataCache.push(event.data); | ||
}); | ||
|
||
|
||
setInterval(() => { | ||
fetch('/api/data') | ||
.then(response => response.json()) | ||
.then(data => { | ||
|
||
dataCache = data; | ||
document.dispatchEvent(new CustomEvent('data-received', { detail: data })); | ||
}); | ||
}, 1000); | ||
} | ||
|
||
|
||
function compareSecretToken(userToken) { | ||
const secretToken = "abc123xyz789"; | ||
let isMatch = true; | ||
|
||
for (let i = 0; i < userToken.length; i++) { | ||
if (userToken[i] !== secretToken[i]) { | ||
isMatch = false; | ||
break; | ||
} | ||
|
||
for (let j = 0; j < 10000; j++) { } | ||
} | ||
|
||
return isMatch; | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
Plan lives here |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,61 @@ | ||
# Security Vulnerabilities in interfaces.js | ||
|
||
## Critical Vulnerabilities | ||
|
||
1. **Cross-Site Scripting (XSS)** - `displayUserMessage()` function | ||
- Directly inserts user input into the DOM without sanitization | ||
- Line 4: `document.getElementById('message').innerHTML = userInput;` | ||
- Impact: Allows attackers to inject and execute malicious scripts | ||
- Recommendation: Use textContent instead of innerHTML or implement proper input sanitization | ||
|
||
2. **Insecure Data Storage** - `saveUserCredentials()` function | ||
- Stores passwords in plaintext in localStorage | ||
- Lines 9-12: Storing sensitive credentials in client-side storage | ||
- Impact: Any script with access to localStorage can steal user credentials | ||
- Recommendation: Never store passwords client-side; use secure authentication methods | ||
|
||
3. **Insecure Direct Object Reference (IDOR)** - `fetchUserData()` function | ||
- No authorization checks when accessing user data | ||
- Line 17: `fetch(`/api/users/${userId}/data`)` without verification | ||
- Impact: Attackers can access other users' data by modifying the userId parameter | ||
- Recommendation: Implement proper authentication and authorization checks | ||
|
||
4. **Code Injection via eval()** - `calculateUserInput()` function | ||
- Uses eval() on user-provided input | ||
- Line 26: `return eval(mathExpression);` | ||
- Impact: Allows execution of arbitrary code provided by users | ||
- Recommendation: Use safer alternatives like a math library or Function constructor | ||
|
||
## High Severity | ||
|
||
5. **Hardcoded API Key** - Global constant | ||
- Sensitive credential exposed in client-side code | ||
- Line 30: `const API_KEY = "sk_test_12345abcdef";` | ||
- Impact: API key can be extracted and misused | ||
- Recommendation: Store API keys server-side and never expose them in client code | ||
|
||
6. **Prototype Pollution** - `mergeObjects()` function | ||
- Recursive object merging without proper checks | ||
- Lines 33-41: Vulnerable implementation of deep merge | ||
- Impact: Attackers can modify object prototypes leading to various attacks | ||
- Recommendation: Use proper deep clone/merge libraries or implement prototype checks | ||
|
||
## Medium Severity | ||
|
||
7. **Memory Leak & Event Listeners** - `startDataProcessing()` function | ||
- Event listener is never removed | ||
- Line 48-50: Adding event listener without cleanup | ||
- Impact: Memory usage increases over time leading to degraded performance | ||
- Recommendation: Properly remove event listeners when no longer needed | ||
|
||
8. **Race Condition** - `startDataProcessing()` function | ||
- Shared resource access without synchronization | ||
- Lines 53-60: Concurrent access to dataCache | ||
- Impact: Unpredictable behavior and potential data corruption | ||
- Recommendation: Implement proper locking mechanisms or use atomic operations | ||
|
||
9. **Timing Attack Vulnerability** - `compareSecretToken()` function | ||
- Non-constant time comparison of secrets | ||
- Lines 67-76: Character-by-character comparison with early exit | ||
- Impact: Allows attackers to derive the secret token through timing analysis | ||
- Recommendation: Use constant-time comparison functions or libraries |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,5 @@ | ||
Flask==2.0.1 | ||
numpy==1.21.0 | ||
Werkzeug>=2,<3 | ||
Flask-Limiter==3.5.0 | ||
marshmallow==3.20.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing newline at the end of file. Adding a newline at the end of text files is a good practice for compatibility with Unix text processing tools and to avoid 'No newline at end of file' warnings in version control systems.