I'm a total newbie to the whole web hacking situation!
I'm writing an IIS based webapp, which will enable primary schools in the UK to upload and analyse pupil (student) performance throughout the year.
Initially I would like to try to set this up with using SSL, really just to enable a couple of schools to trial it while I tweak the app etc.

Anyhow, my question is, if a hacker was to intercept one of the plain text files being uploaded, what other info could they potentially find during the 'interception'.

The actual text file itself would only hold things such as:
an ID for the student which is internal to the school
the pupil's name
the subject (Maths etc)
The grade/level acheived

Just to provide a little more info, the user will have already logged in prior to uploading the file. Their username and a 20-digit 'security code' assigned during login are stored in a cookie, as well as that same info stored in a server side token. Use of the different pages of the application are only allowed if the cookie info matches the server token and this information isn't sent during the upload process (or at least, not intentionally).

I guess what I'm asking is, if a hacker intercepted this text file, would they automatically be privvy to other information like the cookie/token?

I'm making the assumption at this point that the hacker hasn't directly targetted the web server, but has somehow simply intercepted the text file being uploaded.

Again, I will point out I am a total newbie to hacking processes and capabilities and would really appreciate any guidance given. If you need more info then I'll try to supply it.

Thanks in advance - I'll go back to reading all these very interesting posts!

If the 20 digit token is stored as a cookie, then it will be automatically included in all requests including the request to send the file to the server. If the site is properly using SSL though, then an attacker who is eavesdropping on the network communication will only be able to see encrypted data (the cookies and text file will be encrypted).

There are however, many other possible attack scenarios you should be aware of besides just an attacker eavesdropping on network traffic. What happens if an attacker directly browsers to certain restricted URLs? Could the authentication system be bypassed? Is the 20 digit token generated securely or could a malicious attacker infer/brute-force valid tokens? Could a malicious text file be created and uploaded to the website? Could normal GET/POST parameters be tampered with to inject malicious html/javascript/SQL (Cross-site scripting, SQL injection)? etc etc etc.

Many more details would need to be known about the application in order to fully explore all possible threats and attack scenarios. It's not easy to get it all right which is why application security companies get paid big bucks to do application risk assessments, source code analysis, penetration tests, etc on web applications such as this.

the 20-digit token is generated at the time of login. It is only inserted into the token and cookie if the user has used an existing username and password combination. So, I would hope it is impossible to browse directly to an unauthorised URL as the 20-digit key would not have been generated and would not be in the cookie and token and so they'd simply get an authorisation failure notice. Also there would be no server-side password stored as they did not type this in on the login page - so again authorisation would fail.

I do realise there are many different ways that a site and its content can be compromised, my main concern at the moment would be:
what other information could a hacker/eavesdropper find if they had intercepted this plain text file that was being uploaded. Would they know things like the IP addresses of both the sender and destination server of the file?

The easiest would be to download a proxy interceptor tool and see for yourself. Try Web Scarab from owasp.org, or Burp Suite from portswigger.net or Paros proxy from http://www.parosproxy.org/index.shtml .

Each tool should have directions on how to get your web traffic routed through the proxy where you can see the full contents of what's getting passed back and forth (the directions for Burp can be found at http://portswigger.net/proxy/help.html#using ). If your site is using SSL then your browser will give you a SSL cert warning/error because the certificate won't match because the proxy interceptor tool will essentially be doing a Man-in-the-Middle attack and providing its own certificate to the browser - just accept the forged certificate. When you submit the text file that you are asking about, you'll see (in the history log or live, if you are actively intercepting all traffic) everything else that goes along with that request including any cookies, other headers, other GET and POST parameters that are included with the request, destination address, etc.

An attacker would also be able to see the source IP addresses as well, but you probably won't see that in Burp nor its kin. For that, you need to look at the TCP/IP traffic layers using a tool like WireShark, available from http://www.wireshark.org .