Skip to content

Fix for Issue #161 – Unauthorized Avatar Access and IDOR #162

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
64 changes: 64 additions & 0 deletions avatar-leak-idor.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
This pull request corresponds to the vulnerability described in Issue #161[https://github.com/AIxBlock-2023/awesome-ai-dev-platform-opensource/issues/161] – Unauthorized Access to Avatar Images & IDOR via User Profile API.

The application suffers from two related access control issues:

**Public Avatar Access**

User avatars are stored in the /data/avatars/ directory with predictable filenames. These files are accessible without authentication, allowing anyone with the filename (even after the avatar is replaced) to view them directly.

**IDOR via /api/user/{id}**

This endpoint returns limited profile data (ID, name, email, avatar filename) for any user ID. It requires authentication but allows cross-user access, enabling enumeration of avatar filenames. When combined with public access to avatar URLs, this creates an IDOR and privacy leak.

**Proposed Code Fix**

**1. Restrict Access to Avatar Files**

Serve avatar images via an authenticated view that checks ownership or admin privileges

```
# views.py
from django.contrib.auth.decorators import login_required
from django.http import FileResponse, HttpResponseForbidden
from django.shortcuts import get_object_or_404
from myapp.models import User

@login_required
def get_avatar(request, user_id):
target_user = get_object_or_404(User, id=user_id)

if request.user != target_user and not request.user.is_staff:
return HttpResponseForbidden("Unauthorized access.")

avatar_path = target_user.profile.avatar.path
return FileResponse(open(avatar_path, 'rb'), content_type="image/jpeg")
```

**2. Remove Avatar Field from Cross-User /api/user/{id}**

Only return the avatar field when the authenticated user is requesting their own data:

```
# serializers.py
class UserSerializer(serializers.ModelSerializer):
class Meta:
model = User
fields = ['id', 'first_name', 'last_name', 'username'] # No avatar by default

def to_representation(self, instance):
data = super().to_representation(instance)
request = self.context.get('request')

if request.user == instance or request.user.is_staff:
data['avatar'] = instance.profile.avatar.url

return data
```

These changes ensure that:

- Avatar files cannot be accessed directly without authentication.

- /api/user/{id} no longer leaks avatar filenames unless authorized.

- The app enforces proper boundaries between users to protect profile images.
6 changes: 6 additions & 0 deletions reports/account-deletion-idor-placeholder.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
This pull request serves as a placeholder for the account deletion vulnerability reported in Issue #58, where any authenticated user can delete another user’s account by modifying the user ID in the /api/users/{user_id} endpoint.

This commit adds a minimal placeholder to fulfill the bug submission requirements.

Awaiting further instructions from the maintainers. Thank you.

7 changes: 7 additions & 0 deletions reports/internal-metadata-exposure.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
This pull request is a placeholder related to the infrastructure metadata exposure issue I reported in issue #116.

The endpoint `https://app.aixblock.io/api/settings/installation-service/` reveals internal configuration data such as Docker image names, environment types, registry URLs, and version info — all of which should ideally be restricted to internal or admin roles.

This placeholder commit is made from my fork as part of the official submission requirements.

Looking forward to any feedback or next steps. Thank you!