network profile
| bio | website | |
|---|---|---|
| location | Omaha, NE | |
| age | 33 | |
| visits | member for | 1 year, 9 months |
| seen | Aug 15 '12 at 15:24 | |
| stats | profile views | 3 |
I'm currently studying my Master's in computer science while working for a fortune-500 insurance company. I plan on specializing in secure coding, most notably, building defensible applications. (Yeah I know... nearly impossible...)
I'm here to try (and sometimes fail) answering questions; to deepen my knowledge and meet people to code projects with.
Thanks for reading!
alert('If you can read this, SO did their job correctly!');
|
Jan 14 |
awarded | Popular Question |
|
Jul 17 |
revised |
Better techniques than url parameter encryption Changed http links in example to https, and added a small update. |
|
Jul 17 |
accepted | Better techniques than url parameter encryption |
|
Jul 17 |
awarded | Supporter |
|
Jul 17 |
comment |
Better techniques than url parameter encryption I apologize, I extend "roles' to mean: A Manager-->CanSee 1:M Supervisor(s)-->CanSee 1:M Agents. (Note the single direction of the arrows.) Theres no field in these data structures to allow me to make these comparisons. The data model is hypernormalized. (Normal queries can require 9 table joins). My decision was based on "what can I get done by release in 4h?" My favored solution is pretty much exactly what you discuss. It's not an option for me until my DBA gets back and can explain this IAA model. Thank you, btw. At least you validated my original idea was right. |
|
Jul 16 |
comment |
Better techniques than url parameter encryption I added some extra information in the original question to help guide you where I'm presently at. At the present state of the application, I have no ability to perform role-based checking as what you suggest here. It requires changing a megalith recursive-DB as well as changes throughout the entire persistence layer. To be blunt, despite my protests, despite the SANS training they sent me to get, they don't care because the data isn't sensitive. So I'm more or less fumbling for something serviceable... |
|
Jul 16 |
awarded | Editor |
|
Jul 16 |
comment |
Better techniques than url parameter encryption I will stress that SSL is already being used. I'm not concerned with what's between client and server, I'm concerned with what the client will be sending in to snoop. |
|
Jul 16 |
revised |
Better techniques than url parameter encryption Added extra information regarding the nature of the solution I'm trying to improve. |
|
Jul 16 |
comment |
Better techniques than url parameter encryption Not a protocol. We're using SSL, but I'm worried about parameter manipulation from the client, not the points between client/server. |
|
Jul 16 |
asked | Better techniques than url parameter encryption |
|
Aug 20 |
awarded | Scholar |
|
Aug 20 |
accepted | Secure Web Password Fields + http to https redirect |
|
Aug 20 |
comment |
Secure Web Password Fields + http to https redirect OWASP said that the big risk is in a MITM intercepting the originating http GET response from the server and writing over the POST to evil.com. In my case, the set of users is limited to the team I work on, but they all used cheap passwords when they saw 'http' as well. |
|
Aug 20 |
comment |
Secure Web Password Fields + http to https redirect WebScarab is OWASP's web proxy tool. So my concern was related to whether or not I was viewing the message before the transmission down the SSL pipe. I don't have a definitive answer on that yet, but I pulled up the http spec on POST to give me some answers. Note, I'm more concerned that I can see the plaintext AT ALL on this site. Any machine with malware can harvest what it wants. If it was MY app... https the whole way... |
|
Aug 20 |
awarded | Student |
|
Aug 19 |
asked | Secure Web Password Fields + http to https redirect |
|
Aug 18 |
awarded | Autobiographer |
