IDOR: a job can be assigned a hashfile belonging to another customer

Severity: High — broken customer data segregation (IDOR).

Location: `hashview/jobs/routes.py:400-404` (in `jobs_assigned_hashfile`)

elif request.method == 'POST' and request.form.get('hashfile_id'):
    job.hashfile_id = request.form['hashfile_id']   # no ownership/customer check
    db.session.commit()
    return redirect("/jobs/" + str(job.id)+"/notifications")

The posted `hashfile_id` is assigned to the job with no verification that the hashfile belongs to `job.customer_id`. Any authenticated user can attach another customer's hashfile to their job by posting that id.

Confirmed behavior: With job J in customer A and hashfile H in customer B, `POST /jobs//assigned_hashfile/` with `hashfile_id=` sets `job.hashfile_id = H`. Verified with a Flask test-client reproduction on `v0.8.3-dev` (`job.customer=1, hf.customer=2, job.hashfile_id=2`).

Fix: validate the selected hashfile belongs to the job's customer before assigning, e.g.:

hf = Hashfiles.query.filter_by(id=request.form['hashfile_id'], customer_id=job.customer_id).first()
if hf is None:
    flash('Invalid hashfile selection.', 'danger')
    return redirect(url_for('jobs.jobs_assigned_hashfile', job_id=job.id))
job.hashfile_id = hf.id

Start in jobs/routes.py:400-404 at the jobs_assigned_hashfile POST handler, then review the related job and hashfile customer fields. Use the reported Flask test-client reproduction to verify that a cross-customer selection is rejected while a same-customer selection still succeeds. Done means the assignment cannot cross customer boundaries and the existing redirect flow remains usable.