glaztech: commit final Tom message + quo() fix-list

- 2026-06-05-tom-message-draft.md: Mike's final relief-framed wording
- 2026-06-05-quo-sql-fix-list.md: 80 live quo call sites across 15 files (C3)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-06-05 11:22:57 -07:00
parent 9e98ca00cf
commit 185a329770
2 changed files with 83 additions and 32 deletions

View File

@@ -0,0 +1,68 @@
# Glaztech — `quo()` SQL parameterization fix list (for Tom)
**Date:** 2026-06-05 · **Source:** live tree on `WWW` (`D:\web\glaztech_4`), via GuruRMM read-only `findstr`
(excludes stale `Old_bin\` / `Old_code\` copies). Addresses assessment finding **C3**.
## What this is
Every place the site builds dynamic SQL with the `quo()` helper (which wraps a value in quotes but does
**not** escape embedded quotes → SQL injection). The fix is to **parameterize** these statements (use
`SqlParameter`/`@params` instead of `quo()`-concatenation), then delete the `quo()` helper. No redesign —
it's a mechanical, repetitive change.
- **80 `quo()` call sites** across **15 live files** (these are the line-level edits).
- That's roughly the **~59 concatenated SQL statements** the assessment counted — several statements use
multiple `quo()` values per statement, so call-sites (80) > statements (~59). Both numbers are right.
- Priority: the **payment / order / quote pages** (where customer input flows) first; the rest for completeness.
## Count per file
| Sites | File |
|---:|---|
| 15 | `ach.aspx.vb` |
| 14 | `customer-login\online-payment-pnc.aspx.vb` |
| 14 | `customer-login\online-payment-ach-na.aspx.vb` |
| 12 | `customer-login\quote-detail.aspx.vb` |
| 12 | `customer-login\order-detail.aspx.vb` |
| 2 | `quick-pay-ach.aspx.vb` |
| 2 | `quick-pay.aspx.vb` |
| 2 | `quick-pay-pnc.aspx.vb` |
| 1 | `customer-login\Order-acknowledgements.aspx.vb` |
| 1 | `customer-login\order-acknowledgements-approval.aspx.vb` |
| 1 | `customer-login\online-payment-old.aspx.vb` |
| 1 | `customer-login\settings.aspx.vb` |
| 1 | `customer-login\CustomExportPdf.aspx.vb` |
| 1 | `gs\appearance-makeup.aspx.vb` |
| 1 | `gs\performance-makeup.aspx.vb` |
## Full list (file : line)
```
ach.aspx.vb:224, 276, 277, 278, 279, 280, 282, 283, 284, 285, 286, 634, 671, 1246, 1248
customer-login\online-payment-pnc.aspx.vb:1151, 1326, 1383, 1384, 1385, 1386, 1387, 1389, 1390, 1391, 1392, 1394, 1593, 1629
customer-login\online-payment-ach-na.aspx.vb:1208, 1388, 1444, 1445, 1446, 1447, 1448, 1450, 1451, 1452, 1453, 1454, 1653, 1692
customer-login\quote-detail.aspx.vb:96, 97, 98, 101, 102, 103, 286, 288, 310, 312, 1625, 1627
customer-login\order-detail.aspx.vb:113, 114, 115, 118, 119, 120, 299, 301, 321, 323, 1712, 1714
quick-pay.aspx.vb:880, 882
quick-pay-ach.aspx.vb:888, 890
quick-pay-pnc.aspx.vb:656, 658
customer-login\Order-acknowledgements.aspx.vb:384
customer-login\order-acknowledgements-approval.aspx.vb:39
customer-login\online-payment-old.aspx.vb:1152
customer-login\settings.aspx.vb:167
customer-login\CustomExportPdf.aspx.vb:564
gs\appearance-makeup.aspx.vb:211
gs\performance-makeup.aspx.vb:175
```
## Notes
- `quo()` is defined **per page** (not one shared helper). Explicit `Function quo` definitions confirmed in
`gs\appearance-makeup.aspx.vb:494` and `gs\performance-makeup.aspx.vb:482`; the payment pages carry their
own local copies. So "delete `quo()`" means removing each page's local copy after its call sites are fixed.
- The 12 stale copies under `Old_bin\` / `Old_code\` are **not** in this list (not the live code) — but those
duplicate trees should be removed from the production host separately (assessment H1 / item 20).
- Each page should be **tested after** parameterization (no staging — H1), confirming the queries still return
correct results, on a maintenance window with rollback.
- `online-payment-old.aspx.vb` looks like a legacy page — confirm whether it's still reachable; if dead, remove
rather than fix.

View File

@@ -1,8 +1,7 @@
# Draft message to Tom (for Mike's review before sending)
# Draft message to Tom (Mike's final wording, 2026-06-05)
**Channel:** suggest a direct email or Teams/Slack to Tom — NOT buried in the #32378 security ticket
(that ticket carries the full alarming findings; this message is intentionally light and solution-focused).
**Tone goal:** lead with relief; one concrete, bounded ask; respect the 20 years; no threat-model dump.
**Channel:** direct email or Teams/Slack to Tom — NOT buried in the #32378 security ticket.
**Tone:** partnership / not-a-fire-drill; one concrete bounded ask (the 59-ish SQL queries, with line numbers).
---
@@ -10,45 +9,29 @@
Hi Tom,
We know the last few days have been stressful — the security scan dropped a real bomb in your lap, and
we don't take that lightly. Believe me when I say we're here to help: to keep Glaztech safe, and to help
**you** with the security side of the network and the site. You've kept this running for a long time — we're
not here to second-guess any of that. We're here to take the security weight off your shoulders and work
it *with* you.
We know the last few days have been stressful — the security scan dropped a real bomb in your lap, and we don't take that lightly. Believe me when I say we're here to help: to keep Glaztech safe, and to help you with the security side of the network and the site. You've kept this running for a long time — we're not here to second-guess any of that. We're here to take the security weight off your shoulders and work it with you.
Here's the reassuring part, now that we've had time to dig in: **this doesn't have to be a fire drill.**
What the deeper look showed is that the site, the GTIware tools, and the database all tie together pretty
tightly — and *because* of that, the right move is a calm, staged plan, not a rushed scramble. We handle
the urgent, self-contained pieces on our side right away, and work through the rest methodically,
together, without disrupting your day-to-day or your billing.
Here's the reassuring part, now that we've had time to dig in: this doesn't have to be a fire drill. What the deeper look showed is that the site, the GTIware tools, and the database all tie together pretty tightly — and because of that, the right move is a calm, staged plan, not a rushed scramble. We handle the urgent, self-contained pieces on our side right away, and work through the rest methodically, together, without disrupting your day-to-day. At least as much I can, I'll try not to be a nuisance.
So here's what we're proposing.
The heavy infrastructure security is squarely our lane, and we'll carry it:
- Locking down the server and tightening the database permissions
- Putting a web application firewall in front of the site
- Tightening the network/firewall around the database server
Locking down the server and tightening the database permissions
Putting a web application firewall in front of the site
Tightening the network/firewall around the database server
And there's one place where your knowledge of the app is exactly what's needed — and where we'd be working
side by side with you. There's a specific set of **~59 older SQL queries** in the site that build their
statements by stitching text together; switching those to use parameters is the single highest-value code
change for hardening the site. It's contained and repetitive — no redesign, no new frameworks. **We'll
hand you the exact list — files and line numbers — and walk it with you on a call if that's easier**, so
it's a real collaboration, not a hand-off.
And there's one place where your knowledge of the app is exactly what's needed — and where we'd be working side by side with you. There's a specific set of ~59 older SQL queries in the site that build their statements by stitching text together; switching those to use parameters is the single highest-value code change for hardening the site. It's contained and repetitive — no redesign, no new frameworks. I'll get you the exact changes I need, down to the line number if that helps, so you can review them and make the changes.
Down the road there's a bigger item — modernizing how saved cards/payments are handled — but that's a
project we'll plan and scaffold **with** you when there's bandwidth. No rush; we'll carry the legwork.
Down the road there's a bigger item — modernizing how saved cards/payments are handled — but that's a project we'll plan and scaffold with you when there's bandwidth. No rush; we'll carry the legwork.
Bottom line: you're not on the hook to become a security expert overnight, this isn't a five-alarm
scramble, and you're not in this alone. We've got the infrastructure side, we'll hand you a clear, bounded
list for the code piece, and we'll work it together at a sane pace. Let me know a good time to connect.
Bottom line: you're not on the hook to become a security expert overnight, this isn't a five-alarm scramble, and you're not in this alone. We've got the infrastructure side, we'll hand you a clear, bounded list for the code piece, and we'll work it together at a sane pace. Let me know a good time to connect.
Thanks,
Mike / Arizona Computer Guru
---
### Notes for Mike (not part of the message)
- **Prerequisite before sending:** ACG should run the §2a source grep first so the "exact list of 59 lines/files" is actually in hand when Tom replies — don't promise the list and then make him wait. (Assessment C3 names the files: `ach.aspx.vb`, `quick-pay-ach.aspx.vb`, `quick-pay-pnc.aspx.vb`, `quick-pay.aspx.vb`, `order-detail*` + the `quo()` definition.)
- **Held back deliberately** (keep the first ask minimal): the customer-vs-employee path-map review and the `/emp/` VPN-gating. Raise those as a separate, lighter touch once the 59-query ask is moving, or have ACG derive the map from logs/source and just confirm a couple of points with him.
- **Not mentioned:** the full threat model, plaintext passwords, the domain-admin/`msdb`/`xp_cmdshell` chain — all ACG-side, handled without burdening Tom.
### Notes for Mike
- Optional tiny grammar fix in para 3: *"At least as much **as** I can, I'll try not to be a nuisance."* — left your wording as-is otherwise.
- **Prerequisite before sending:** the exact line-number list for the SQL queries — ACG grep in progress (80 live `quo()` call sites found on WWW; producing the per-file:line list now). The message promises "down to the line number," so have it ready when Tom replies.
- Held back deliberately (minimal first ask): the customer-vs-employee path-map review and the `/emp/` VPN-gatingraise separately/lighter later.