Site Menu
- Policy & Standards
- University
- Institutional Data
- Disclosure or Exposure of Personal Information
- Responsible Use of University Computing and Network Resources
- Archives and Records Retention
- Merchant Services & Use of Credit Cards
- Deployment and Use of Wireless Data Networks
- Statement on Public Records
- Draft Identity Theft Red Flags
- State & Federal
- Institutional Data
- Training
- Tools & Templates
- Standards & Frameworks
- FAQ
- Alternative Identifiers
- Data Classification and Access Control
- Gramm-Leach-Bliley Training
- Identity Theft Red Flag Training
- Information Security Implementation Plan
- Institutional Data Policy
- Institutional Data Policy Training
- Red Flags
- Restricted Data
- Social Security Numbers
- University Security Standards
- Campus Resources
- Contact Us
- Site Map
What's New?
- Identity Theft Red Flags Training begins.
- Learn about an IT Security Framework.
Hot Topics
- Institutional Data Policy Training
- Restricted Data Elements
- Implementation Plan
- University Security Standards (UCSS)
- Relevant Federal Laws & Regulations
2008-2009 IT Security Implementation Plan update!
The dates for the quarterly implementation plan submissions have been updated to reflect the 2008-2009 schedule.
Incident Response
Web Service Security Standard (WSSS) FAQ
Below are common questions regarding the WSSS. If your question is not listed, please use the email form at the bottom of this page to contact us.
- If I make a web service or server inaccessible outside of my department or unit, does this standard apply?
- What is secure code? (9.1)
- What is a self-signed certificate versus a root certificate authority (CA)? (8.1.1)
- What are some resources for keeping up-to-date with patches?
- Why must I monitor anonymous comments? (6.6)
- Why should web uploads be stored outside of the document root? (6.5)
- What are some resource for learning about and preventing SQL injections?
- What are some resources for learning about and preventing cross-site scripting vulnerabilities?
- How do I scan my websites for injection flaws and other vulnerabilities?
- What kind of authentication methods are available university-wide?
- What training is available?
- What logs would be useful for an incident investigation?
- What is server-side validation? (9.6)
- Does a proxy/security proxy server bring me into compliance?
If I make a web service or server inaccessible outside of my department or unit, does this standard apply?
No, this standard applies only to servers that are accessible outside of a department or unit. However, all of the requirements of this document are strongly recommended for all web servers.
What is secure code? (9.1)
Secure code is code that does not contain security vulnerabilities such as SQL injection flaws, Cross-Site Scripting vulnerabilities, etc.
What is a self-signed certificate versus a root certificate authority (CA)? (8.1.1)
A self-signed certificate is it’s own root CA. A self-signed certificate can not be validated because it is not signed by a well-known certificate root CA, therefore a client cannot be sure of the true identity of the server providing the self-signed certificate.
What are some resources for keeping up-to-date with patches?
The following may be useful for keeping up-to-date with the latest releases of popular software:
- The Cassandra Tool (https://cassandra.cerias.purdue.edu/)
- ISC-SANS (http://isc.sans.org/)
- US-CERT (http://www.us-cert.gov/)
- CVE (http://cve.mitre.org/)
- Vendor-supplied update utility (e.g. Microsoft Update)
Why must I monitor anonymous comments? (6.6)
Anonymous comments may be used to post inappropriate content, from which a severe loss of reputation to the University might ensue; or from which significant legal costs might be incurred.
Why should web uploads be stored outside of the document root? (6.5)
The intent of this stipulation is to prevent someone from directly accessing content that they may have just uploaded. If someone uploads a PHP script to your web server, and your server is configured to store uploads within the main web site directory structure, and your server is configured to execute PHP scripts from within the main web site directory or sub-directories, then the uploader could directly request the URL to the uploaded file and have your server execute their script.
If you are unable to store uploads outside of your document root, there are a variety of ways to still permit uploads while protecting your site:
- Configure your server to not execute dynamic content (PHP, ASP, etc) from the directory in which you store uploads
- Configure your server to not permit direct requests to files stored in your upload directory
What are some resource for learning about and preventing SQL injections?
One of the most important assumptions about SQL injection is: assume that all data coming from the client (web browser) is suspicious. Preventing SQL injection then deals with filtering this data on the server side. If your scripting language allows parameterized queries, that is a great line of defense. For common scripting languages, here are some particular resources:
More generic information regarding SQL injections can be found at the following:
What are some resources for learning about and preventing cross-site scripting vulnerabilities?
Generic information regarding Cross-Site Scripting can be found at the following:
How do I scan my websites for injection flaws and other vulnerabilities?
The following are well-known scanning utilities, but should be used at your own risk:
What kind of authentication methods are available university-wide?
One option is Shibboleth:
Depending on your development language and platform, you may be able to authenticate against your department's Active Directory or LDAP service, if you have one:
What training is available?
This will depend greatly on your role and your department. The University does not currently offer training classes for secure web development. A variety of local companies do provide such training, though:
What logs would be useful for an incident investigation?
At the least, the web server's access and error logs are required. These permit the security response team to see what URLs were requested at what time by whom, as well as any error conditions that were reported as a result of these requests. Many attackers evaluate your server's response to invalid requests in order to learn of mistakes or vulnerabilities in your configuration.
If your web application records log data, that is useful. Any record of user logon (successes and failures), permission escalation (becoming an admin user in your web application, for example), or user activity (user "scott" modified the content of item #23 in the inventory system, for example) will help the security team.
What is server-side validation? (9.6)
Server-side validation means that the web service residing on the web server hosting the web service validates the data input from a user before taking any action on it (e.g. inserting it into a database). This is in contrast to client-side validation, which is typically implemented using Javascript to validate the data with the user's browser before submitting it to the web service.
Does a proxy/security proxy server bring me into compliance?
No, a proxy server or proxy server providing security services (i.e. ISA Server) does not bring a server into compliance. However, any opportunity to implement layered security is recommended.
Further Questions?
If you have a question about the above standard, please use the form below to contact the Office of the CIO. We will respond to your inquiry as soon as possible.
