I have a question that is more conceptual at the moment than anything else.
Here's my situation
The school that I go to has a website for grade viewing which can be found at this link: https://grades.bsd405.org/Pinnacle/Gradebook/InternetViewer/Default.aspx
The login page presents a username and password box.
I plan on constructing a simple iPhone app that takes the resultant grades that are listed and display them in a UITableView.
However, how would I achieve getting the data from this website?
How do websites validate (authenticate) usernames and passwords and then pass on the relevant data?
Thanks for bearing through this tough question.
There are a lot of things going on in this website; i think we would need a little more info from you on your specific request. When you say Validate, do you mean validate as in check that usernames and passwords are formatted correctly or do you mean validate as in authenticate, i.e. send the resultant data to the X to determine that the username and password is correct.
Based on what I see I can partially answer your question, the asp site would send over SSL, the user name and password to the application, where I would assume the application then checks the username and password against a username and hash of the password (the hash being the calculated squish of the password which is stored as such for security and confidentiality).
In your case you wouldn't need to know any of that if you wanted to interface/integrate an app with this, you'd just need to format a request in your app and deliver it over an SSL connnection to the page. There's a caveat; and that being session stuff with ASP; its a bit more complex than just usernames and passwords.
The page generate a unique ID each time, passed as hidden field of the form. So i'm sorry but i think that you can't post nothing from the extern.
Yes, you certain can pass the hidden id.
What you need to do is follow the session stuff that ASP generates. We do this all the time with ASP sites that we 'scrape' for data with our primary application.
Your app will first need to call the site, collect the sessionid data, and return that in your form when you submit the form for authentication. After that depending on what is happening in the site, you may need to capture and send the resultant sessionid on each subsequent request.
Actually its a horrible thing when you see how much useless data is passed back and forth by ASP.
Related
I am sending a GET Parameter which is an ID, of course this ID is needed to pull fields from salesforce using the soapclient API.
My issue is because this parameter can easily be changed by a user to a different ID, on load of my page it will pull up other fields based on that other ID the user had altered.
How can I secure this in some form? whether it is from the salesforce end or the php side, My Solutions I came up with are the following but I found tedious.
Have a field in salesforce that is ticked if user has submitted the data before so old data can not be viewed again when it does a check to see if it was submitted.
Create a session, grab the get parameter, then redirect to the same page. but that is a bit tedious.
What is the best solution for handling a GET Parameter from a salesforce link that will arrive in a email to the user?
I'm not sure how you generate these ID's or where you use them. But if you store them somewhere and then retrieve them at a later time you could try and hash them. When the ID gets generated either hash it right away and use this hash as the identifier or, if you only get the ID at a later point (on insertion for example), you could create a hash out of the generated ID and store it in a different field of the same record. Later when you are retrieving or showing records to the user you can hash the ID again and make only requests using the hash. This would be a pretty difficult way for the user to get any other records since they would have to know the hash that was generated for the ID.
Of course it all depends a bit on your implementation. I don't have any personal experience with salesforce, so I don't know what might or might not be preventing you from implementing such an idea.
I'm writing a small app that gets information from the server, allows the user to manipulate it, then saves it back to the server. When getting the information from the server, the server also gives a password. When the information gets sent back to the server, the server looks for the password, as a safety precaution.
My question is, what is a safe way to pass the password after the form submits? I considered hidden fields, but that would make it possible to find the password.
Any ideas?
You can store it in a session with a specific field defining of password and destroying after made in use.
This is much better usage.
You could give the password to Javascript/jQuery and then intercept the normal form submit, append the password to the post data, and then resubmit the form, but that may be a bit overkill...
As long as the password isn't being used for anything else (as in it's randomly generated) and it's single use, putting it in a hidden field shouldn't be much of an issue. Average users don't know how to view hidden fields. However, if you are connecting over HTTP and not HTTPS, your average hacker would be able to view the password coming over the unencrypted network and potentially use it before your user can.
How Do i secure vote buttons in server-side like here on Stackoverflow? I've seen how the button can be submitted in this answer, But how about in the server side, how do I protect the voting system from csrf attacks and such?
bots generally doesn't run javascript, so just check on server side if it was an AJAX call.
If you want to be more protected maybe append a param generated automatically by javascript with some calc based on current time, then check on your server if it's match with the same calc
A widely accepted way to protect from CSRF is to use a nonce. When the button is clicked and a request is submitted via AJAX or POST data, a nonce value is passed along with it. That nonce is then verified on the backend. You can have that nonce value stored in the session upon generation, possibly using hashing / salting so that the nonce can be specific to a certain action, ie 'vote-up', 'vote-down', etc.
See:
need help understanding nonce
Put a unique id in the GET query portion of each arrow link. That way the attacker / spoofer cannot know to which address to direct the CSRF attack.
The easiest and most effective way is probably to require all users who desire to vote to signup, so that you can keep track of who is voting on each post. As soon as you know who every voter is, you save the user id along with every vote, then you can easily validate that the users hasn't previously voted on a specific question.
Then of course you have to protect your sign up form, to make sure that bots can't register, but that can be done using reCAPTCHA and other similar methods. You will probably also try to limit the users from registering for more than one account. That is of course tricky, but you can at least start of by requiring unique email-addresses for every account, or make use of some third part authentication like Google, Facebook etc.
If you don't want to require sign up, then I guess you have to fallback on registering the IP-address of every vote, but going down that road is trickier. Bots will probably use a whole range of IP-addresses, and you might ending up blocking votes from different users who happens to share the same IP - which can be really annoying.
You can require a Login and even use openid for that.
Is there a way to only let a webpage be viewed if the link pointing to it is pressed. I am sending emails to members of my organization with links that attach values to the URL so I can use phps $_GET to figure out who they are on the webpage and update appropriately. What I am worried about is individuals changing the values of the link and changing other members data. If there is a better method for doing this, I am all ears. Using a log in system is not an option.
Not exactly, no.
What you could do is include some token that you keep associated with a particular user id and is very difficult to guess, and include that in the link as well - then, when you get a GET request, you check to make sure the token matches the one you know is correct for that userid. (You'd store the "correct" tokens locally in a database when sending out the emails.)
For instance, you might have...
/modify_info_script?user_id=123&token=aSDqWEqwejk2123salskq
And then you'd have a database table or some other storage that has...
user_id token
----------------------
... ...
122 klqwkejajwie8u8213nak
123 aSDqWEqwejk2123salskq
... ...
and thus if someone tried to change the user_id in the URL, the token wouldn't match and you could reject their request. For instance, this would get rejected...
/modify_info_script?user_id=122&token=aSDqWEqwejk2123salskq
since the right token for 122 would be klqwkejajwie8u8213nak, not aSDqWEqwejk2123salskq.
This is probably the best option if using a login system isn't an option. However, you should really make sure that using a login system isn't an option at all, because user data really should be protected by a login.
This is really not the proper way to secure your site.
However, the simple fix for you is to check the "referer" header and make sure it's not blank. If it's not blank, then it came from a click (or they spoofed it, which is why this isn't secure).
The real way to protect data is to implement a login system with a set of permissions.
To check, if someone came from a link, see $_SERVER['HTTP_REFERER'].
To protect the application against link manipulation, you can combine it with a secret passphrase (only internally, the passphrase must not be known to anyone) and use md5() on the result. Attach the MD5 to the url. If anyone manipulates the url, you will know because the MD5 of "the url plus your passphrase minus the MD5" will be different.
Quite a lot password reset systems work like this so you could say it's reasonably safe provided you use long enough random token. Something like 32 chars should be fine.
Just providing the token should be enough since you don't need the user ID to check it against issued tokens in database.
/modify_info_script?token=aSDqWEqwejk2123salskqfilltill32chars
The other alternative is to have login system where use has to type in their credentials in order to change information.
Also if you really fear that someone might try to guess it, just timeout/ban users after 3 wrong token attempts. No one should be trying to type them in by hand anyway.
I have
echo <a href=\"javascript:;\" onClick=\"window.open('". $link ."','no','scrollbars=yes,width=550,height=400')\" >View report</a>
$link contains sensitive information, so I'm wondering if there is a simple way to prevent this link showing up explicitly when you "view source code" on the browser. Any alternative to href would be fine. I just need to give the user an option to click and see his processing result after he submits some data. I would like to avoid having auto popups as soon as the processing is submitted.
UPDATE: so the $link is a GET URL that includes a user ID and password.. It's internal right now so it's fine, but I'm thinking of putting this on our online server in the future. I'm very much a novice with PHP, so this is probably not in the near future as I don't know much about security features that need to be implemented for a live site on the Internet. Right now, it seems that utilizing a database would be the best way to go. Correct me if I'm wrong, please, and thanks for all of the support!
If the user has to navigate to the link, there is no way to actually hide the information. You should rethink how your process works so sensitive information is not displayed in the link.
Perhaps you can store the information in a database table and the link would just use the id of the row that has the information.
Simply put: No. If you send me to a URL, I will be able to see it using some sort of tool. Wireshark, Fiddler, etc. Consider using a different link structure.
If the user already owns a session, this is an option:
If you render a page and need to protect this given sample secret URL
http://www.MyHost.com/?what?secret&id=23232
save the URL in the user's session and associate a hash value with the secret URL.
Instead of sending the URL to the result HTML-page, insert another URL, e.g.
http://www.MyHost.com/?continueWith=<hashValue>
If this URL gets called, check the user's session and retrieve and delete the secret URL. Then continue to evaluate, as if the user had called the secret URL.
This way, no parameter of the original secret URL ever reaches the user's browser.
To refine the schema, attach a lifetime to the URL saved in the session. If a request comes later as the end of life, return an error.
If you protect all URL in such a way, users won't be able to call arbitrary URLs, since all acceptable URLs are those inside their sessions. Thus, a user will even not be able to change parameters of less secret URLs.
How is $link generated in the first place? If it is sensitive, this implies that the user has already been authenticated somehow. Thus, the information in $link can be stored in the session where it's safe
Save all the information in your PHP session (or preferably the session system your PHP framework uses) and then just send some kind of non-db-associated identifier in the link so that the code knows what you want to do next.
For example you could have a link to "http://www.yourdomain.com/sec/special_action/4" with "sec" meaning secure, "special_action" being the name of the action to take, and "4" being the action id reference.
So lets say you have to have it associated to their social security number. Then you would in your back end use a salted hash to encrypt the SSN and save it to the session data. You then append it to the end of your session array and get an array count. If it returns 5 then you know that the encrypted SSN is saved in index 4 (since PHP uses 0 based indexing). So you send along that index as part of the link to confuse things even more. Heck you can even salt and hash the index if you want.
The user clicks on the link, the code finds the index, grabs the encrypted content, decrypts it, then uses it. Easy and secure.