Fix broken access control vulnerability in settings API - #67

Open
theiris6 wants to merge 281 commits into
thoth-tech:9.xfrom
theiris6:fix/BAC-setting-endponit
Open

Fix broken access control vulnerability in settings API#67
theiris6 wants to merge 281 commits into
thoth-tech:9.xfrom
theiris6:fix/BAC-setting-endponit

Conversation

@theiris6

@theiris6theiris6 commented May 12, 2025

Copy link
Copy Markdown

Description

This PR addresses a critical vulnerability identified in the security audit report (ref: BAC.md).
The Settings API was exposing sensitive configuration data without proper authentication, which could allow unauthorized users to access system configuration details.

Fixes # (issue)

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

Files Modified:

app/api/settings_api.rb:

  • Added helpers AuthenticationHelpers and helpers AuthorisationHelpers at the top of the class
  • Added authenticated? check to the main /settings endpoint to require authentication
  • Added authenticated? check to the /settings/privacy endpoint to require authentication
  • Created a new /settings/public endpoint that only returns non-sensitive information (externalName)
  • Moved sensitive configuration data (overseerEnabled, tiiEnabled, d2lEnabled) to be accessible only to authenticated users

app/api/api_root.rb:

  • Added AuthenticationHelpers.add_auth_to SettingsApi in the "Add auth details to all endpoints" section

  • This ensures all protected settings endpoints require proper authentication headers

API Changes:

  1. Protected Endpoint -/api/settings:
  • Now requires valid authentication headers (Username and Auth-Token)
  • Returns full settings data including sensitive integration status for authenticated users
  • Returns 419 error with authentication message for unauthenticated requests
  1. New Public Endpoint -/api/settings/public:
  • Accessible without authentication
  • Returns only non-sensitive settings (externalName)
  • Allows frontend to retrieve basic application information without authentication
  1. Protected Endpoint - /api/settings/privacy:
  • Now requires valid authentication headers
  • Contains sensitive privacy policy information that should only be accessible to authenticated users

How Has This Been Tested?

  • Verified unauthenticated requests to /api/settings return proper 419 authentication errors
  • Confirmed authenticated requests to /api/settings return complete configuration data
  • Tested that /api/settings/public is accessible without authentication
  • Validated that only non-sensitive data is returned from the public endpoint
  • Re-ran the security audit test script which now passes for this vulnerability
  • Manually verified the fix addresses the specific issue identified in the security audit report

Security Impact:

This fix prevents unauthorized users from accessing sensitive system configuration details. Previously, an attacker could determine which integrations were enabled (TurnItIn, D2L, Overseer) and potentially use this information to target specific attack vectors. The fix now ensures proper access controls are in place while still allowing the application to function normally.

Resolves security issue identified in vulnerability report BAC.md.

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation if appropriate
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • I have created or extended unit tests to address my new additions
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules

TinyServaland others added 30 commits June 24, 2024 21:55
- Implement methods in task_definition model for numbas data management
- Implement routes in task_definition_api for numbas data managemnt
- Remove unused upload API in numbas_api
maciteand others added 20 commits January 30, 2025 23:49
- refactor to allow different file roots
- remove need for portfolio evidence attribute, while still working with existing values
Use new environment variable to enable archive - false by default.
- use archive folder when unit archived
- move submission history to archive folder when unit archived
- move submission history on task abbr change
- move submission history on username change
- delete submission history on task delete
- action is too slow for use in sidekiq
- removed from scheduled actions
- Modified app/api/settings_api.rb to require authentication for sensitive endpoints
- Created a new public endpoint for non-sensitive settings
- Added authentication requirement to privacy settings endpoint
- Added SettingsApi to the authentication helpers list in app/api/api_root.rb
- Prevents unauthorized access to system configuration

@EkamBhullarEkamBhullar left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @theiris6 , PR looks good, I tried accessing the settings endpoint without authenticating and it gave me error as expected and public endpoint worked properly
image.

The PR addresses a critical security vulnerability and implements the fix in a clean, maintainable way. However, I believe,

-Basic Error Handling can be added in /settings endpoint, in case if there is any loading failure.

Also, do you think authenticated check can also be added in /settings/privacy?

@returnMarcco

returnMarcco commented May 20, 2025

Copy link
Copy Markdown

Hi @theiris6,

Can you please replace me with somebody else for this PR as at the moment, I'm unable to build the backend for any branch based on the 8.x branch. I've also sent you a private message in Teams.

Cheers

Added authentication check for /settings/privacy endpoint
@theiris6

Copy link
Copy Markdown
Author

Hi @theiris6,

Can you please replace me with somebody else for this PR as at the moment, I'm unable to build the backend for any branch based on the 8.x branch. I've also sent you a private message in Teams.

Cheers

Thank you for reviewing my PR and testing the fix! I'm glad to see that the implementation is working as expected, with the main settings endpoint properly requiring authentication while the public endpoint is accessible.

Based on your feedback, I've made both suggested improvements:

  1. Added authentication to the privacy settings endpoint.

  2. Implemented error handling for the settings endpoints to improve robustness. The application will now properly catch and log any configuration loading failures, returning an appropriate error message to the user instead of potentially crashing.

Let me know if you have any other suggestions or if these changes look good to you!

@EkamBhullarEkamBhullar left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great Job on fixing this vulnerability, I have verified, it works properly and you have made Changes requested.

@aNebula

Copy link
Copy Markdown

LGTM.
@theiris6 please open an upstream PR with these changes and description against 9.x branch on doubtfire-lms/doubtfire-api.
This will be recorded as contribution in your public github portfolio - which can help during job applications.

@theiris6
theiris6 changed the base branch from app-attack-fixes to 9.xJuly 18, 2025 07:49
@theiris6
theiris6 changed the base branch from 9.x to app-attack-fixesJuly 18, 2025 07:49
@theiris6
theiris6 changed the base branch from app-attack-fixes to 9.xJuly 25, 2025 06:55
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants

@theiris6@returnMarcco@aNebula@EkamBhullar@TinyServal@satikaj@macite
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Skip to content

Fix broken access control vulnerability in settings API - #67

Open
theiris6 wants to merge 281 commits into
thoth-tech:9.xfrom
theiris6:fix/BAC-setting-endponit
Open

Fix broken access control vulnerability in settings API#67
theiris6 wants to merge 281 commits into
thoth-tech:9.xfrom
theiris6:fix/BAC-setting-endponit

Conversation

@theiris6

@theiris6theiris6 commented May 12, 2025

Copy link
Copy Markdown

Description

This PR addresses a critical vulnerability identified in the security audit report (ref: BAC.md).
The Settings API was exposing sensitive configuration data without proper authentication, which could allow unauthorized users to access system configuration details.

Fixes # (issue)

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

Files Modified:

app/api/settings_api.rb:

  • Added helpers AuthenticationHelpers and helpers AuthorisationHelpers at the top of the class
  • Added authenticated? check to the main /settings endpoint to require authentication
  • Added authenticated? check to the /settings/privacy endpoint to require authentication
  • Created a new /settings/public endpoint that only returns non-sensitive information (externalName)
  • Moved sensitive configuration data (overseerEnabled, tiiEnabled, d2lEnabled) to be accessible only to authenticated users

app/api/api_root.rb:

  • Added AuthenticationHelpers.add_auth_to SettingsApi in the "Add auth details to all endpoints" section

  • This ensures all protected settings endpoints require proper authentication headers

API Changes:

  1. Protected Endpoint -/api/settings:
  • Now requires valid authentication headers (Username and Auth-Token)
  • Returns full settings data including sensitive integration status for authenticated users
  • Returns 419 error with authentication message for unauthenticated requests
  1. New Public Endpoint -/api/settings/public:
  • Accessible without authentication
  • Returns only non-sensitive settings (externalName)
  • Allows frontend to retrieve basic application information without authentication
  1. Protected Endpoint - /api/settings/privacy:
  • Now requires valid authentication headers
  • Contains sensitive privacy policy information that should only be accessible to authenticated users

How Has This Been Tested?

  • Verified unauthenticated requests to /api/settings return proper 419 authentication errors
  • Confirmed authenticated requests to /api/settings return complete configuration data
  • Tested that /api/settings/public is accessible without authentication
  • Validated that only non-sensitive data is returned from the public endpoint
  • Re-ran the security audit test script which now passes for this vulnerability
  • Manually verified the fix addresses the specific issue identified in the security audit report

Security Impact:

This fix prevents unauthorized users from accessing sensitive system configuration details. Previously, an attacker could determine which integrations were enabled (TurnItIn, D2L, Overseer) and potentially use this information to target specific attack vectors. The fix now ensures proper access controls are in place while still allowing the application to function normally.

Resolves security issue identified in vulnerability report BAC.md.

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation if appropriate
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • I have created or extended unit tests to address my new additions
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules

TinyServaland others added 30 commits June 24, 2024 21:55
- Implement methods in task_definition model for numbas data management
- Implement routes in task_definition_api for numbas data managemnt
- Remove unused upload API in numbas_api
maciteand others added 20 commits January 30, 2025 23:49
- refactor to allow different file roots
- remove need for portfolio evidence attribute, while still working with existing values
Use new environment variable to enable archive - false by default.
- use archive folder when unit archived
- move submission history to archive folder when unit archived
- move submission history on task abbr change
- move submission history on username change
- delete submission history on task delete
- action is too slow for use in sidekiq
- removed from scheduled actions
- Modified app/api/settings_api.rb to require authentication for sensitive endpoints
- Created a new public endpoint for non-sensitive settings
- Added authentication requirement to privacy settings endpoint
- Added SettingsApi to the authentication helpers list in app/api/api_root.rb
- Prevents unauthorized access to system configuration

@EkamBhullarEkamBhullar left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @theiris6 , PR looks good, I tried accessing the settings endpoint without authenticating and it gave me error as expected and public endpoint worked properly
image.

The PR addresses a critical security vulnerability and implements the fix in a clean, maintainable way. However, I believe,

-Basic Error Handling can be added in /settings endpoint, in case if there is any loading failure.

Also, do you think authenticated check can also be added in /settings/privacy?

@returnMarcco

returnMarcco commented May 20, 2025

Copy link
Copy Markdown

Hi @theiris6,

Can you please replace me with somebody else for this PR as at the moment, I'm unable to build the backend for any branch based on the 8.x branch. I've also sent you a private message in Teams.

Cheers

Added authentication check for /settings/privacy endpoint
@theiris6

Copy link
Copy Markdown
Author

Hi @theiris6,

Can you please replace me with somebody else for this PR as at the moment, I'm unable to build the backend for any branch based on the 8.x branch. I've also sent you a private message in Teams.

Cheers

Thank you for reviewing my PR and testing the fix! I'm glad to see that the implementation is working as expected, with the main settings endpoint properly requiring authentication while the public endpoint is accessible.

Based on your feedback, I've made both suggested improvements:

  1. Added authentication to the privacy settings endpoint.

  2. Implemented error handling for the settings endpoints to improve robustness. The application will now properly catch and log any configuration loading failures, returning an appropriate error message to the user instead of potentially crashing.

Let me know if you have any other suggestions or if these changes look good to you!

@EkamBhullarEkamBhullar left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great Job on fixing this vulnerability, I have verified, it works properly and you have made Changes requested.

@aNebula

Copy link
Copy Markdown

LGTM.
@theiris6 please open an upstream PR with these changes and description against 9.x branch on doubtfire-lms/doubtfire-api.
This will be recorded as contribution in your public github portfolio - which can help during job applications.

@theiris6
theiris6 changed the base branch from app-attack-fixes to 9.xJuly 18, 2025 07:49
@theiris6
theiris6 changed the base branch from 9.x to app-attack-fixesJuly 18, 2025 07:49
@theiris6
theiris6 changed the base branch from app-attack-fixes to 9.xJuly 25, 2025 06:55
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants

@theiris6@returnMarcco@aNebula@EkamBhullar@TinyServal@satikaj@macite
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Fix broken access control vulnerability in settings API - #67

Open
theiris6 wants to merge 281 commits into
thoth-tech:9.xfrom
theiris6:fix/BAC-setting-endponit
Open

Fix broken access control vulnerability in settings API#67
theiris6 wants to merge 281 commits into
thoth-tech:9.xfrom
theiris6:fix/BAC-setting-endponit

Conversation

@theiris6

@theiris6theiris6 commented May 12, 2025

Copy link
Copy Markdown

Description

This PR addresses a critical vulnerability identified in the security audit report (ref: BAC.md).
The Settings API was exposing sensitive configuration data without proper authentication, which could allow unauthorized users to access system configuration details.

Fixes # (issue)

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

Files Modified:

app/api/settings_api.rb:

  • Added helpers AuthenticationHelpers and helpers AuthorisationHelpers at the top of the class
  • Added authenticated? check to the main /settings endpoint to require authentication
  • Added authenticated? check to the /settings/privacy endpoint to require authentication
  • Created a new /settings/public endpoint that only returns non-sensitive information (externalName)
  • Moved sensitive configuration data (overseerEnabled, tiiEnabled, d2lEnabled) to be accessible only to authenticated users

app/api/api_root.rb:

  • Added AuthenticationHelpers.add_auth_to SettingsApi in the "Add auth details to all endpoints" section

  • This ensures all protected settings endpoints require proper authentication headers

API Changes:

  1. Protected Endpoint -/api/settings:
  • Now requires valid authentication headers (Username and Auth-Token)
  • Returns full settings data including sensitive integration status for authenticated users
  • Returns 419 error with authentication message for unauthenticated requests
  1. New Public Endpoint -/api/settings/public:
  • Accessible without authentication
  • Returns only non-sensitive settings (externalName)
  • Allows frontend to retrieve basic application information without authentication
  1. Protected Endpoint - /api/settings/privacy:
  • Now requires valid authentication headers
  • Contains sensitive privacy policy information that should only be accessible to authenticated users

How Has This Been Tested?

  • Verified unauthenticated requests to /api/settings return proper 419 authentication errors
  • Confirmed authenticated requests to /api/settings return complete configuration data
  • Tested that /api/settings/public is accessible without authentication
  • Validated that only non-sensitive data is returned from the public endpoint
  • Re-ran the security audit test script which now passes for this vulnerability
  • Manually verified the fix addresses the specific issue identified in the security audit report

Security Impact:

This fix prevents unauthorized users from accessing sensitive system configuration details. Previously, an attacker could determine which integrations were enabled (TurnItIn, D2L, Overseer) and potentially use this information to target specific attack vectors. The fix now ensures proper access controls are in place while still allowing the application to function normally.

Resolves security issue identified in vulnerability report BAC.md.

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation if appropriate
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • I have created or extended unit tests to address my new additions
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules

TinyServaland others added 30 commits June 24, 2024 21:55
- Implement methods in task_definition model for numbas data management
- Implement routes in task_definition_api for numbas data managemnt
- Remove unused upload API in numbas_api
maciteand others added 20 commits January 30, 2025 23:49
- refactor to allow different file roots
- remove need for portfolio evidence attribute, while still working with existing values
Use new environment variable to enable archive - false by default.
- use archive folder when unit archived
- move submission history to archive folder when unit archived
- move submission history on task abbr change
- move submission history on username change
- delete submission history on task delete
- action is too slow for use in sidekiq
- removed from scheduled actions
- Modified app/api/settings_api.rb to require authentication for sensitive endpoints
- Created a new public endpoint for non-sensitive settings
- Added authentication requirement to privacy settings endpoint
- Added SettingsApi to the authentication helpers list in app/api/api_root.rb
- Prevents unauthorized access to system configuration

@EkamBhullarEkamBhullar left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @theiris6 , PR looks good, I tried accessing the settings endpoint without authenticating and it gave me error as expected and public endpoint worked properly
image.

The PR addresses a critical security vulnerability and implements the fix in a clean, maintainable way. However, I believe,

-Basic Error Handling can be added in /settings endpoint, in case if there is any loading failure.

Also, do you think authenticated check can also be added in /settings/privacy?

@returnMarcco

returnMarcco commented May 20, 2025

Copy link
Copy Markdown

Hi @theiris6,

Can you please replace me with somebody else for this PR as at the moment, I'm unable to build the backend for any branch based on the 8.x branch. I've also sent you a private message in Teams.

Cheers

Added authentication check for /settings/privacy endpoint
@theiris6

Copy link
Copy Markdown
Author

Hi @theiris6,

Can you please replace me with somebody else for this PR as at the moment, I'm unable to build the backend for any branch based on the 8.x branch. I've also sent you a private message in Teams.

Cheers

Thank you for reviewing my PR and testing the fix! I'm glad to see that the implementation is working as expected, with the main settings endpoint properly requiring authentication while the public endpoint is accessible.

Based on your feedback, I've made both suggested improvements:

  1. Added authentication to the privacy settings endpoint.

  2. Implemented error handling for the settings endpoints to improve robustness. The application will now properly catch and log any configuration loading failures, returning an appropriate error message to the user instead of potentially crashing.

Let me know if you have any other suggestions or if these changes look good to you!

@EkamBhullarEkamBhullar left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great Job on fixing this vulnerability, I have verified, it works properly and you have made Changes requested.

@aNebula

Copy link
Copy Markdown

LGTM.
@theiris6 please open an upstream PR with these changes and description against 9.x branch on doubtfire-lms/doubtfire-api.
This will be recorded as contribution in your public github portfolio - which can help during job applications.

@theiris6
theiris6 changed the base branch from app-attack-fixes to 9.xJuly 18, 2025 07:49
@theiris6
theiris6 changed the base branch from 9.x to app-attack-fixesJuly 18, 2025 07:49
@theiris6
theiris6 changed the base branch from app-attack-fixes to 9.xJuly 25, 2025 06:55
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants

@theiris6@returnMarcco@aNebula@EkamBhullar@TinyServal@satikaj@macite
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Fix broken access control vulnerability in settings API - #67

Open
theiris6 wants to merge 281 commits into
thoth-tech:9.xfrom
theiris6:fix/BAC-setting-endponit
Open

Fix broken access control vulnerability in settings API#67
theiris6 wants to merge 281 commits into
thoth-tech:9.xfrom
theiris6:fix/BAC-setting-endponit

Conversation

@theiris6

@theiris6theiris6 commented May 12, 2025

Copy link
Copy Markdown

Description

This PR addresses a critical vulnerability identified in the security audit report (ref: BAC.md).
The Settings API was exposing sensitive configuration data without proper authentication, which could allow unauthorized users to access system configuration details.

Fixes # (issue)

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

Files Modified:

app/api/settings_api.rb:

  • Added helpers AuthenticationHelpers and helpers AuthorisationHelpers at the top of the class
  • Added authenticated? check to the main /settings endpoint to require authentication
  • Added authenticated? check to the /settings/privacy endpoint to require authentication
  • Created a new /settings/public endpoint that only returns non-sensitive information (externalName)
  • Moved sensitive configuration data (overseerEnabled, tiiEnabled, d2lEnabled) to be accessible only to authenticated users

app/api/api_root.rb:

  • Added AuthenticationHelpers.add_auth_to SettingsApi in the "Add auth details to all endpoints" section

  • This ensures all protected settings endpoints require proper authentication headers

API Changes:

  1. Protected Endpoint -/api/settings:
  • Now requires valid authentication headers (Username and Auth-Token)
  • Returns full settings data including sensitive integration status for authenticated users
  • Returns 419 error with authentication message for unauthenticated requests
  1. New Public Endpoint -/api/settings/public:
  • Accessible without authentication
  • Returns only non-sensitive settings (externalName)
  • Allows frontend to retrieve basic application information without authentication
  1. Protected Endpoint - /api/settings/privacy:
  • Now requires valid authentication headers
  • Contains sensitive privacy policy information that should only be accessible to authenticated users

How Has This Been Tested?

  • Verified unauthenticated requests to /api/settings return proper 419 authentication errors
  • Confirmed authenticated requests to /api/settings return complete configuration data
  • Tested that /api/settings/public is accessible without authentication
  • Validated that only non-sensitive data is returned from the public endpoint
  • Re-ran the security audit test script which now passes for this vulnerability
  • Manually verified the fix addresses the specific issue identified in the security audit report

Security Impact:

This fix prevents unauthorized users from accessing sensitive system configuration details. Previously, an attacker could determine which integrations were enabled (TurnItIn, D2L, Overseer) and potentially use this information to target specific attack vectors. The fix now ensures proper access controls are in place while still allowing the application to function normally.

Resolves security issue identified in vulnerability report BAC.md.

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation if appropriate
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • I have created or extended unit tests to address my new additions
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules

TinyServaland others added 30 commits June 24, 2024 21:55
- Implement methods in task_definition model for numbas data management
- Implement routes in task_definition_api for numbas data managemnt
- Remove unused upload API in numbas_api
maciteand others added 20 commits January 30, 2025 23:49
- refactor to allow different file roots
- remove need for portfolio evidence attribute, while still working with existing values
Use new environment variable to enable archive - false by default.
- use archive folder when unit archived
- move submission history to archive folder when unit archived
- move submission history on task abbr change
- move submission history on username change
- delete submission history on task delete
- action is too slow for use in sidekiq
- removed from scheduled actions
- Modified app/api/settings_api.rb to require authentication for sensitive endpoints
- Created a new public endpoint for non-sensitive settings
- Added authentication requirement to privacy settings endpoint
- Added SettingsApi to the authentication helpers list in app/api/api_root.rb
- Prevents unauthorized access to system configuration

@EkamBhullarEkamBhullar left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @theiris6 , PR looks good, I tried accessing the settings endpoint without authenticating and it gave me error as expected and public endpoint worked properly
image.

The PR addresses a critical security vulnerability and implements the fix in a clean, maintainable way. However, I believe,

-Basic Error Handling can be added in /settings endpoint, in case if there is any loading failure.

Also, do you think authenticated check can also be added in /settings/privacy?

@returnMarcco

returnMarcco commented May 20, 2025

Copy link
Copy Markdown

Hi @theiris6,

Can you please replace me with somebody else for this PR as at the moment, I'm unable to build the backend for any branch based on the 8.x branch. I've also sent you a private message in Teams.

Cheers

Added authentication check for /settings/privacy endpoint
@theiris6

Copy link
Copy Markdown
Author

Hi @theiris6,

Can you please replace me with somebody else for this PR as at the moment, I'm unable to build the backend for any branch based on the 8.x branch. I've also sent you a private message in Teams.

Cheers

Thank you for reviewing my PR and testing the fix! I'm glad to see that the implementation is working as expected, with the main settings endpoint properly requiring authentication while the public endpoint is accessible.

Based on your feedback, I've made both suggested improvements:

  1. Added authentication to the privacy settings endpoint.

  2. Implemented error handling for the settings endpoints to improve robustness. The application will now properly catch and log any configuration loading failures, returning an appropriate error message to the user instead of potentially crashing.

Let me know if you have any other suggestions or if these changes look good to you!

@EkamBhullarEkamBhullar left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great Job on fixing this vulnerability, I have verified, it works properly and you have made Changes requested.

@aNebula

Copy link
Copy Markdown

LGTM.
@theiris6 please open an upstream PR with these changes and description against 9.x branch on doubtfire-lms/doubtfire-api.
This will be recorded as contribution in your public github portfolio - which can help during job applications.

@theiris6
theiris6 changed the base branch from app-attack-fixes to 9.xJuly 18, 2025 07:49
@theiris6
theiris6 changed the base branch from 9.x to app-attack-fixesJuly 18, 2025 07:49
@theiris6
theiris6 changed the base branch from app-attack-fixes to 9.xJuly 25, 2025 06:55
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants

@theiris6@returnMarcco@aNebula@EkamBhullar@TinyServal@satikaj@macite
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
Skip to content

Fix broken access control vulnerability in settings API - #67

Open
theiris6 wants to merge 281 commits into
thoth-tech:9.xfrom
theiris6:fix/BAC-setting-endponit
Open

Fix broken access control vulnerability in settings API#67
theiris6 wants to merge 281 commits into
thoth-tech:9.xfrom
theiris6:fix/BAC-setting-endponit

Conversation

@theiris6

@theiris6theiris6 commented May 12, 2025

Copy link
Copy Markdown

Description

This PR addresses a critical vulnerability identified in the security audit report (ref: BAC.md).
The Settings API was exposing sensitive configuration data without proper authentication, which could allow unauthorized users to access system configuration details.

Fixes # (issue)

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

Files Modified:

app/api/settings_api.rb:

  • Added helpers AuthenticationHelpers and helpers AuthorisationHelpers at the top of the class
  • Added authenticated? check to the main /settings endpoint to require authentication
  • Added authenticated? check to the /settings/privacy endpoint to require authentication
  • Created a new /settings/public endpoint that only returns non-sensitive information (externalName)
  • Moved sensitive configuration data (overseerEnabled, tiiEnabled, d2lEnabled) to be accessible only to authenticated users

app/api/api_root.rb:

  • Added AuthenticationHelpers.add_auth_to SettingsApi in the "Add auth details to all endpoints" section

  • This ensures all protected settings endpoints require proper authentication headers

API Changes:

  1. Protected Endpoint -/api/settings:
  • Now requires valid authentication headers (Username and Auth-Token)
  • Returns full settings data including sensitive integration status for authenticated users
  • Returns 419 error with authentication message for unauthenticated requests
  1. New Public Endpoint -/api/settings/public:
  • Accessible without authentication
  • Returns only non-sensitive settings (externalName)
  • Allows frontend to retrieve basic application information without authentication
  1. Protected Endpoint - /api/settings/privacy:
  • Now requires valid authentication headers
  • Contains sensitive privacy policy information that should only be accessible to authenticated users

How Has This Been Tested?

  • Verified unauthenticated requests to /api/settings return proper 419 authentication errors
  • Confirmed authenticated requests to /api/settings return complete configuration data
  • Tested that /api/settings/public is accessible without authentication
  • Validated that only non-sensitive data is returned from the public endpoint
  • Re-ran the security audit test script which now passes for this vulnerability
  • Manually verified the fix addresses the specific issue identified in the security audit report

Security Impact:

This fix prevents unauthorized users from accessing sensitive system configuration details. Previously, an attacker could determine which integrations were enabled (TurnItIn, D2L, Overseer) and potentially use this information to target specific attack vectors. The fix now ensures proper access controls are in place while still allowing the application to function normally.

Resolves security issue identified in vulnerability report BAC.md.

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation if appropriate
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • I have created or extended unit tests to address my new additions
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules

TinyServaland others added 30 commits June 24, 2024 21:55
- Implement methods in task_definition model for numbas data management
- Implement routes in task_definition_api for numbas data managemnt
- Remove unused upload API in numbas_api
maciteand others added 20 commits January 30, 2025 23:49
- refactor to allow different file roots
- remove need for portfolio evidence attribute, while still working with existing values
Use new environment variable to enable archive - false by default.
- use archive folder when unit archived
- move submission history to archive folder when unit archived
- move submission history on task abbr change
- move submission history on username change
- delete submission history on task delete
- action is too slow for use in sidekiq
- removed from scheduled actions
- Modified app/api/settings_api.rb to require authentication for sensitive endpoints
- Created a new public endpoint for non-sensitive settings
- Added authentication requirement to privacy settings endpoint
- Added SettingsApi to the authentication helpers list in app/api/api_root.rb
- Prevents unauthorized access to system configuration

@EkamBhullarEkamBhullar left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @theiris6 , PR looks good, I tried accessing the settings endpoint without authenticating and it gave me error as expected and public endpoint worked properly
image.

The PR addresses a critical security vulnerability and implements the fix in a clean, maintainable way. However, I believe,

-Basic Error Handling can be added in /settings endpoint, in case if there is any loading failure.

Also, do you think authenticated check can also be added in /settings/privacy?

@returnMarcco

returnMarcco commented May 20, 2025

Copy link
Copy Markdown

Hi @theiris6,

Can you please replace me with somebody else for this PR as at the moment, I'm unable to build the backend for any branch based on the 8.x branch. I've also sent you a private message in Teams.

Cheers

Added authentication check for /settings/privacy endpoint
@theiris6

Copy link
Copy Markdown
Author

Hi @theiris6,

Can you please replace me with somebody else for this PR as at the moment, I'm unable to build the backend for any branch based on the 8.x branch. I've also sent you a private message in Teams.

Cheers

Thank you for reviewing my PR and testing the fix! I'm glad to see that the implementation is working as expected, with the main settings endpoint properly requiring authentication while the public endpoint is accessible.

Based on your feedback, I've made both suggested improvements:

  1. Added authentication to the privacy settings endpoint.

  2. Implemented error handling for the settings endpoints to improve robustness. The application will now properly catch and log any configuration loading failures, returning an appropriate error message to the user instead of potentially crashing.

Let me know if you have any other suggestions or if these changes look good to you!

@EkamBhullarEkamBhullar left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great Job on fixing this vulnerability, I have verified, it works properly and you have made Changes requested.

@aNebula

Copy link
Copy Markdown

LGTM.
@theiris6 please open an upstream PR with these changes and description against 9.x branch on doubtfire-lms/doubtfire-api.
This will be recorded as contribution in your public github portfolio - which can help during job applications.

@theiris6
theiris6 changed the base branch from app-attack-fixes to 9.xJuly 18, 2025 07:49
@theiris6
theiris6 changed the base branch from 9.x to app-attack-fixesJuly 18, 2025 07:49
@theiris6
theiris6 changed the base branch from app-attack-fixes to 9.xJuly 25, 2025 06:55
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants

@theiris6@returnMarcco@aNebula@EkamBhullar@TinyServal@satikaj@macite
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Fix broken access control vulnerability in settings API - #67

Open
theiris6 wants to merge 281 commits into
thoth-tech:9.xfrom
theiris6:fix/BAC-setting-endponit
Open

Fix broken access control vulnerability in settings API#67
theiris6 wants to merge 281 commits into
thoth-tech:9.xfrom
theiris6:fix/BAC-setting-endponit

Conversation

@theiris6

@theiris6theiris6 commented May 12, 2025

Copy link
Copy Markdown

Description

This PR addresses a critical vulnerability identified in the security audit report (ref: BAC.md).
The Settings API was exposing sensitive configuration data without proper authentication, which could allow unauthorized users to access system configuration details.

Fixes # (issue)

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

Files Modified:

app/api/settings_api.rb:

  • Added helpers AuthenticationHelpers and helpers AuthorisationHelpers at the top of the class
  • Added authenticated? check to the main /settings endpoint to require authentication
  • Added authenticated? check to the /settings/privacy endpoint to require authentication
  • Created a new /settings/public endpoint that only returns non-sensitive information (externalName)
  • Moved sensitive configuration data (overseerEnabled, tiiEnabled, d2lEnabled) to be accessible only to authenticated users

app/api/api_root.rb:

  • Added AuthenticationHelpers.add_auth_to SettingsApi in the "Add auth details to all endpoints" section

  • This ensures all protected settings endpoints require proper authentication headers

API Changes:

  1. Protected Endpoint -/api/settings:
  • Now requires valid authentication headers (Username and Auth-Token)
  • Returns full settings data including sensitive integration status for authenticated users
  • Returns 419 error with authentication message for unauthenticated requests
  1. New Public Endpoint -/api/settings/public:
  • Accessible without authentication
  • Returns only non-sensitive settings (externalName)
  • Allows frontend to retrieve basic application information without authentication
  1. Protected Endpoint - /api/settings/privacy:
  • Now requires valid authentication headers
  • Contains sensitive privacy policy information that should only be accessible to authenticated users

How Has This Been Tested?

  • Verified unauthenticated requests to /api/settings return proper 419 authentication errors
  • Confirmed authenticated requests to /api/settings return complete configuration data
  • Tested that /api/settings/public is accessible without authentication
  • Validated that only non-sensitive data is returned from the public endpoint
  • Re-ran the security audit test script which now passes for this vulnerability
  • Manually verified the fix addresses the specific issue identified in the security audit report

Security Impact:

This fix prevents unauthorized users from accessing sensitive system configuration details. Previously, an attacker could determine which integrations were enabled (TurnItIn, D2L, Overseer) and potentially use this information to target specific attack vectors. The fix now ensures proper access controls are in place while still allowing the application to function normally.

Resolves security issue identified in vulnerability report BAC.md.

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation if appropriate
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • I have created or extended unit tests to address my new additions
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules

TinyServaland others added 30 commits June 24, 2024 21:55
- Implement methods in task_definition model for numbas data management
- Implement routes in task_definition_api for numbas data managemnt
- Remove unused upload API in numbas_api
maciteand others added 20 commits January 30, 2025 23:49
- refactor to allow different file roots
- remove need for portfolio evidence attribute, while still working with existing values
Use new environment variable to enable archive - false by default.
- use archive folder when unit archived
- move submission history to archive folder when unit archived
- move submission history on task abbr change
- move submission history on username change
- delete submission history on task delete
- action is too slow for use in sidekiq
- removed from scheduled actions
- Modified app/api/settings_api.rb to require authentication for sensitive endpoints
- Created a new public endpoint for non-sensitive settings
- Added authentication requirement to privacy settings endpoint
- Added SettingsApi to the authentication helpers list in app/api/api_root.rb
- Prevents unauthorized access to system configuration

@EkamBhullarEkamBhullar left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @theiris6 , PR looks good, I tried accessing the settings endpoint without authenticating and it gave me error as expected and public endpoint worked properly
image.

The PR addresses a critical security vulnerability and implements the fix in a clean, maintainable way. However, I believe,

-Basic Error Handling can be added in /settings endpoint, in case if there is any loading failure.

Also, do you think authenticated check can also be added in /settings/privacy?

@returnMarcco

returnMarcco commented May 20, 2025

Copy link
Copy Markdown

Hi @theiris6,

Can you please replace me with somebody else for this PR as at the moment, I'm unable to build the backend for any branch based on the 8.x branch. I've also sent you a private message in Teams.

Cheers

Added authentication check for /settings/privacy endpoint
@theiris6

Copy link
Copy Markdown
Author

Hi @theiris6,

Can you please replace me with somebody else for this PR as at the moment, I'm unable to build the backend for any branch based on the 8.x branch. I've also sent you a private message in Teams.

Cheers

Thank you for reviewing my PR and testing the fix! I'm glad to see that the implementation is working as expected, with the main settings endpoint properly requiring authentication while the public endpoint is accessible.

Based on your feedback, I've made both suggested improvements:

  1. Added authentication to the privacy settings endpoint.

  2. Implemented error handling for the settings endpoints to improve robustness. The application will now properly catch and log any configuration loading failures, returning an appropriate error message to the user instead of potentially crashing.

Let me know if you have any other suggestions or if these changes look good to you!

@EkamBhullarEkamBhullar left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great Job on fixing this vulnerability, I have verified, it works properly and you have made Changes requested.

@aNebula

Copy link
Copy Markdown

LGTM.
@theiris6 please open an upstream PR with these changes and description against 9.x branch on doubtfire-lms/doubtfire-api.
This will be recorded as contribution in your public github portfolio - which can help during job applications.

@theiris6
theiris6 changed the base branch from app-attack-fixes to 9.xJuly 18, 2025 07:49
@theiris6
theiris6 changed the base branch from 9.x to app-attack-fixesJuly 18, 2025 07:49
@theiris6
theiris6 changed the base branch from app-attack-fixes to 9.xJuly 25, 2025 06:55
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants

@theiris6@returnMarcco@aNebula@EkamBhullar@TinyServal@satikaj@macite
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Fix broken access control vulnerability in settings API - #67

Open
theiris6 wants to merge 281 commits into
thoth-tech:9.xfrom
theiris6:fix/BAC-setting-endponit
Open

Fix broken access control vulnerability in settings API#67
theiris6 wants to merge 281 commits into
thoth-tech:9.xfrom
theiris6:fix/BAC-setting-endponit

Conversation

@theiris6

@theiris6theiris6 commented May 12, 2025

Copy link
Copy Markdown

Description

This PR addresses a critical vulnerability identified in the security audit report (ref: BAC.md).
The Settings API was exposing sensitive configuration data without proper authentication, which could allow unauthorized users to access system configuration details.

Fixes # (issue)

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

Files Modified:

app/api/settings_api.rb:

  • Added helpers AuthenticationHelpers and helpers AuthorisationHelpers at the top of the class
  • Added authenticated? check to the main /settings endpoint to require authentication
  • Added authenticated? check to the /settings/privacy endpoint to require authentication
  • Created a new /settings/public endpoint that only returns non-sensitive information (externalName)
  • Moved sensitive configuration data (overseerEnabled, tiiEnabled, d2lEnabled) to be accessible only to authenticated users

app/api/api_root.rb:

  • Added AuthenticationHelpers.add_auth_to SettingsApi in the "Add auth details to all endpoints" section

  • This ensures all protected settings endpoints require proper authentication headers

API Changes:

  1. Protected Endpoint -/api/settings:
  • Now requires valid authentication headers (Username and Auth-Token)
  • Returns full settings data including sensitive integration status for authenticated users
  • Returns 419 error with authentication message for unauthenticated requests
  1. New Public Endpoint -/api/settings/public:
  • Accessible without authentication
  • Returns only non-sensitive settings (externalName)
  • Allows frontend to retrieve basic application information without authentication
  1. Protected Endpoint - /api/settings/privacy:
  • Now requires valid authentication headers
  • Contains sensitive privacy policy information that should only be accessible to authenticated users

How Has This Been Tested?

  • Verified unauthenticated requests to /api/settings return proper 419 authentication errors
  • Confirmed authenticated requests to /api/settings return complete configuration data
  • Tested that /api/settings/public is accessible without authentication
  • Validated that only non-sensitive data is returned from the public endpoint
  • Re-ran the security audit test script which now passes for this vulnerability
  • Manually verified the fix addresses the specific issue identified in the security audit report

Security Impact:

This fix prevents unauthorized users from accessing sensitive system configuration details. Previously, an attacker could determine which integrations were enabled (TurnItIn, D2L, Overseer) and potentially use this information to target specific attack vectors. The fix now ensures proper access controls are in place while still allowing the application to function normally.

Resolves security issue identified in vulnerability report BAC.md.

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation if appropriate
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • I have created or extended unit tests to address my new additions
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules

TinyServaland others added 30 commits June 24, 2024 21:55
- Implement methods in task_definition model for numbas data management
- Implement routes in task_definition_api for numbas data managemnt
- Remove unused upload API in numbas_api
maciteand others added 20 commits January 30, 2025 23:49
- refactor to allow different file roots
- remove need for portfolio evidence attribute, while still working with existing values
Use new environment variable to enable archive - false by default.
- use archive folder when unit archived
- move submission history to archive folder when unit archived
- move submission history on task abbr change
- move submission history on username change
- delete submission history on task delete
- action is too slow for use in sidekiq
- removed from scheduled actions
- Modified app/api/settings_api.rb to require authentication for sensitive endpoints
- Created a new public endpoint for non-sensitive settings
- Added authentication requirement to privacy settings endpoint
- Added SettingsApi to the authentication helpers list in app/api/api_root.rb
- Prevents unauthorized access to system configuration

@EkamBhullarEkamBhullar left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @theiris6 , PR looks good, I tried accessing the settings endpoint without authenticating and it gave me error as expected and public endpoint worked properly
image.

The PR addresses a critical security vulnerability and implements the fix in a clean, maintainable way. However, I believe,

-Basic Error Handling can be added in /settings endpoint, in case if there is any loading failure.

Also, do you think authenticated check can also be added in /settings/privacy?

@returnMarcco

returnMarcco commented May 20, 2025

Copy link
Copy Markdown

Hi @theiris6,

Can you please replace me with somebody else for this PR as at the moment, I'm unable to build the backend for any branch based on the 8.x branch. I've also sent you a private message in Teams.

Cheers

Added authentication check for /settings/privacy endpoint
@theiris6

Copy link
Copy Markdown
Author

Hi @theiris6,

Can you please replace me with somebody else for this PR as at the moment, I'm unable to build the backend for any branch based on the 8.x branch. I've also sent you a private message in Teams.

Cheers

Thank you for reviewing my PR and testing the fix! I'm glad to see that the implementation is working as expected, with the main settings endpoint properly requiring authentication while the public endpoint is accessible.

Based on your feedback, I've made both suggested improvements:

  1. Added authentication to the privacy settings endpoint.

  2. Implemented error handling for the settings endpoints to improve robustness. The application will now properly catch and log any configuration loading failures, returning an appropriate error message to the user instead of potentially crashing.

Let me know if you have any other suggestions or if these changes look good to you!

@EkamBhullarEkamBhullar left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great Job on fixing this vulnerability, I have verified, it works properly and you have made Changes requested.

@aNebula

Copy link
Copy Markdown

LGTM.
@theiris6 please open an upstream PR with these changes and description against 9.x branch on doubtfire-lms/doubtfire-api.
This will be recorded as contribution in your public github portfolio - which can help during job applications.

@theiris6
theiris6 changed the base branch from app-attack-fixes to 9.xJuly 18, 2025 07:49
@theiris6
theiris6 changed the base branch from 9.x to app-attack-fixesJuly 18, 2025 07:49
@theiris6
theiris6 changed the base branch from app-attack-fixes to 9.xJuly 25, 2025 06:55
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants

@theiris6@returnMarcco@aNebula@EkamBhullar@TinyServal@satikaj@macite
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
Skip to content

Fix broken access control vulnerability in settings API - #67

Open
theiris6 wants to merge 281 commits into
thoth-tech:9.xfrom
theiris6:fix/BAC-setting-endponit
Open

Fix broken access control vulnerability in settings API#67
theiris6 wants to merge 281 commits into
thoth-tech:9.xfrom
theiris6:fix/BAC-setting-endponit

Conversation

@theiris6

@theiris6theiris6 commented May 12, 2025

Copy link
Copy Markdown

Description

This PR addresses a critical vulnerability identified in the security audit report (ref: BAC.md).
The Settings API was exposing sensitive configuration data without proper authentication, which could allow unauthorized users to access system configuration details.

Fixes # (issue)

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

Files Modified:

app/api/settings_api.rb:

  • Added helpers AuthenticationHelpers and helpers AuthorisationHelpers at the top of the class
  • Added authenticated? check to the main /settings endpoint to require authentication
  • Added authenticated? check to the /settings/privacy endpoint to require authentication
  • Created a new /settings/public endpoint that only returns non-sensitive information (externalName)
  • Moved sensitive configuration data (overseerEnabled, tiiEnabled, d2lEnabled) to be accessible only to authenticated users

app/api/api_root.rb:

  • Added AuthenticationHelpers.add_auth_to SettingsApi in the "Add auth details to all endpoints" section

  • This ensures all protected settings endpoints require proper authentication headers

API Changes:

  1. Protected Endpoint -/api/settings:
  • Now requires valid authentication headers (Username and Auth-Token)
  • Returns full settings data including sensitive integration status for authenticated users
  • Returns 419 error with authentication message for unauthenticated requests
  1. New Public Endpoint -/api/settings/public:
  • Accessible without authentication
  • Returns only non-sensitive settings (externalName)
  • Allows frontend to retrieve basic application information without authentication
  1. Protected Endpoint - /api/settings/privacy:
  • Now requires valid authentication headers
  • Contains sensitive privacy policy information that should only be accessible to authenticated users

How Has This Been Tested?

  • Verified unauthenticated requests to /api/settings return proper 419 authentication errors
  • Confirmed authenticated requests to /api/settings return complete configuration data
  • Tested that /api/settings/public is accessible without authentication
  • Validated that only non-sensitive data is returned from the public endpoint
  • Re-ran the security audit test script which now passes for this vulnerability
  • Manually verified the fix addresses the specific issue identified in the security audit report

Security Impact:

This fix prevents unauthorized users from accessing sensitive system configuration details. Previously, an attacker could determine which integrations were enabled (TurnItIn, D2L, Overseer) and potentially use this information to target specific attack vectors. The fix now ensures proper access controls are in place while still allowing the application to function normally.

Resolves security issue identified in vulnerability report BAC.md.

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation if appropriate
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • I have created or extended unit tests to address my new additions
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules

TinyServaland others added 30 commits June 24, 2024 21:55
- Implement methods in task_definition model for numbas data management
- Implement routes in task_definition_api for numbas data managemnt
- Remove unused upload API in numbas_api
maciteand others added 20 commits January 30, 2025 23:49
- refactor to allow different file roots
- remove need for portfolio evidence attribute, while still working with existing values
Use new environment variable to enable archive - false by default.
- use archive folder when unit archived
- move submission history to archive folder when unit archived
- move submission history on task abbr change
- move submission history on username change
- delete submission history on task delete
- action is too slow for use in sidekiq
- removed from scheduled actions
- Modified app/api/settings_api.rb to require authentication for sensitive endpoints
- Created a new public endpoint for non-sensitive settings
- Added authentication requirement to privacy settings endpoint
- Added SettingsApi to the authentication helpers list in app/api/api_root.rb
- Prevents unauthorized access to system configuration

@EkamBhullarEkamBhullar left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @theiris6 , PR looks good, I tried accessing the settings endpoint without authenticating and it gave me error as expected and public endpoint worked properly
image.

The PR addresses a critical security vulnerability and implements the fix in a clean, maintainable way. However, I believe,

-Basic Error Handling can be added in /settings endpoint, in case if there is any loading failure.

Also, do you think authenticated check can also be added in /settings/privacy?

@returnMarcco

returnMarcco commented May 20, 2025

Copy link
Copy Markdown

Hi @theiris6,

Can you please replace me with somebody else for this PR as at the moment, I'm unable to build the backend for any branch based on the 8.x branch. I've also sent you a private message in Teams.

Cheers

Added authentication check for /settings/privacy endpoint
@theiris6

Copy link
Copy Markdown
Author

Hi @theiris6,

Can you please replace me with somebody else for this PR as at the moment, I'm unable to build the backend for any branch based on the 8.x branch. I've also sent you a private message in Teams.

Cheers

Thank you for reviewing my PR and testing the fix! I'm glad to see that the implementation is working as expected, with the main settings endpoint properly requiring authentication while the public endpoint is accessible.

Based on your feedback, I've made both suggested improvements:

  1. Added authentication to the privacy settings endpoint.

  2. Implemented error handling for the settings endpoints to improve robustness. The application will now properly catch and log any configuration loading failures, returning an appropriate error message to the user instead of potentially crashing.

Let me know if you have any other suggestions or if these changes look good to you!

@EkamBhullarEkamBhullar left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great Job on fixing this vulnerability, I have verified, it works properly and you have made Changes requested.

@aNebula

Copy link
Copy Markdown

LGTM.
@theiris6 please open an upstream PR with these changes and description against 9.x branch on doubtfire-lms/doubtfire-api.
This will be recorded as contribution in your public github portfolio - which can help during job applications.

@theiris6
theiris6 changed the base branch from app-attack-fixes to 9.xJuly 18, 2025 07:49
@theiris6
theiris6 changed the base branch from 9.x to app-attack-fixesJuly 18, 2025 07:49
@theiris6
theiris6 changed the base branch from app-attack-fixes to 9.xJuly 25, 2025 06:55
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants

@theiris6@returnMarcco@aNebula@EkamBhullar@TinyServal@satikaj@macite