Fixed python and pylint scripts

[WolveJC]

No description provided.

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[codesandbox]

Review or Edit in CodeSandbox

Open the branch in Web Editor • VS Code • Insiders

Open Preview

In general, the fix is to ensure that any path used to save user-uploaded files does not allow for directory traversal or writing outside a safe upload directory. The industry standard for Flask apps is to use werkzeug.utils.secure_filename to sanitize user filenames, ensuring they are plain filenames without directory information or dangerous characters.

The single best way to fix this issue without changing existing functionality is:

• Before saving the uploaded file, use secure_filename to sanitize file.filename.
• Construct the path using only the sanitized filename.
• Optionally, as a further guard, normalize the resulting path and ensure it remains within the upload directory.

Required changes:

• Add an import: from werkzeug.utils import secure_filename
• Before calling os.path.join, sanitize file.filename with secure_filename.
• Use the sanitized version in all subsequent path uses.

All code changes are inside the shown code in unidad_3/Flask/app.py: the upload route and the import region.

---

To securely handle user file uploads, avoid using the raw filename provided by the user. Instead, use a function such as werkzeug.utils.secure_filename to strip dangerous characters (slashes, dots, etc) and prevent traversal attacks. Additionally, after joining the filename to the upload folder path, normalize the path and ensure it's still contained within the intended root directory. This guards against any potential bypasses that secure_filename may miss.
The fix will require:

• Importing secure_filename from werkzeug.utils.
• Applying secure_filename to file.filename before using it to construct filepath.
• Normalizing the result with os.path.normpath and checking it starts with the upload directory.
• Handling the case where a filename becomes empty or invalid after sanitization.

Changes should be made in the upload_csv function where filepath is constructed and where it is deleted in error-handling. The imports need to include secure_filename.

---

To fix this problem, we need to ensure that any user-provided filename is sanitized before being used to construct a path and interact with the filesystem. The most robust method in this context is to use Flask/Werkzeug's secure_filename function to clean the filename of special or dangerous characters, followed by ensuring that the final path remains within the intended upload directory, even after joining and normalization.

Specifically, in each place where file.filename is used to construct a file path, replace file.filename with its sanitized version from werkzeug.utils.secure_filename, and after joining with UPLOAD_FOLDER, normalize the path with os.path.normpath, then verify that it starts with the expected base upload directory. This protects against both path traversal and absolute path attacks.

This change should be applied in all code regions where file.filename is used to create file paths, namely in the upload_csv function and also anywhere else in the same file where file.filename is used for file operations.

We need to:

• Import secure_filename from werkzeug.utils.
• In the upload_csv function, sanitize file.filename to obtain a safe name, join and normalize it, and verify it is inside the upload folder.
• Use the sanitized path (safe_filepath) in all subsequent file operations, including save, pd.read_csv, session assignment, and deletion.

To fix this vulnerability, remove the debug=True argument from the app.run() call so Flask does not start in debug mode. This prevents exposure of the debugger in any deployment, especially when binding to all interfaces. Only remove the debug argument: do not otherwise alter execution or behavior. No new methods or imports are required; just change the arguments to app.run() on line 481. The fix is in unidad_3/Flask/app.py, within the main execution block.

To fix the problem, add a permissions block to the job definition to restrict GITHUB_TOKEN permissions to the minimum required. Since this workflow does not perform any operations that modify repository contents or interact with issues or pull requests, it is safe and secure to set contents: read. This should be added directly under the job (build:) in .github/workflows/pylint.yml, immediately after runs-on: ubuntu-latest, before steps:. No additional imports or packages are required; this is a YAML/Actions configuration change only. No existing functionality will be affected.

To fix this, do not use request.url as the argument to redirect. Instead, directly redirect to a known-safe internal route, such as the index page, or use url_for("upload_csv") to ensure the user is always returned to the upload page. In this specific context, we want to redirect the user back to the CSV upload form upon error.
Change needed: On line 94, replace redirect(request.url) with redirect(url_for("upload_csv")).
No new imports are required since url_for is already imported.

---

To fix this issue, avoid redirecting to request.url, which can be manipulated by an attacker. Instead, redirect to a safe, known route—typically by using Flask's url_for() function to redirect to a safe handler name, such as the same route that triggered the redirect (in this case, "upload_csv"). This prevents an attacker from controlling the redirection target. Update line 100 to use redirect(url_for("upload_csv")), which simply reloads the page in a safe and predictable manner. No additional imports or method definitions are required, and no loss of functionality should occur, as the user remains on the intended upload page.

To fix the problem, the error message sent to clients should be made generic and not include potentially sensitive details. Exception information should be logged server-side for diagnostics. Concretely:

• In crear_inventario, within the except block on lines 166–167, replace the return statement so that the response does not include e.
• Instead, log the exception details using a safe mechanism (app.logger.error is standard for Flask apps).
• Leave only a generic message in the API response to users.
• You need to add an appropriate import/use of Flask's logger, if not already present.

Affected region:

• unidad_3/Flask/app.py, lines 166–167 (in crear_inventario).
  You do not need to change any exception handling behavior or add new dependencies.

---

To fix this issue, the code at line 355 should be modified so that the exception details ({e}) are not included in the response sent to the user. Instead, the error should be logged on the server for developers to review, and the response should provide a generic error message such as "Error al procesar datos.". This ensures that users do not receive potentially sensitive information about the server's internal workings. The change only affects the exception branch's response message and optionally adds a logging mechanism for debugging server-side. Specifically:

• In pedir_proveedor, change the line return jsonify({"message": f"Error al procesar datos: {e}"}), 400 to return jsonify({"message": "Error al procesar datos."}), 400.
• Ensure the error is logged for developer diagnosis (existing print(f"Error de datos en /pedir_proveedor: {e}") suffices, but for production code use Python's logging library).

No new method or import is strictly required for this code snippet.

---

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
wolvespage	Ready	Preview	Comment	Nov 24, 2025 5:09pm