Top Tips in securing your clients web application for developers a managers guide.
Since I made the move around a year ago to take a break from lecturing and move back into the consultancy world its certainly kept me on my toes. Being a consultant is all about effective communication and essentially being one step ahead. Having a wide network of SME’s you can speak with and extensive research into the latest and most common technologies.
I have found that I often deal with the same repeating issues and vulnerabilities and usually these could of been mitigated or avoided by more consideration and thought in the network architechture phase. I will cover only some of the main issues I have recently dealt with otherwise this article could be the size of a book.
- A picture paints a thousand words
It is absolutely essential whether working with external developers if outsourcing or using an internal team to draw network diagrams. You would be amazed how many encounters I have had where I have asked developers to produce a network diagram ready for a white box penetration test and haven’t been able to do so. This makes the testing for functionality, usability and essentially identification of broken access control alot more difficult or at least eats into time which means more money for the business.
Have a picture ….. is it updated and maintained? The network diagram is a working document, every change to the environment must be documented. This often leads to the business wanting to introduce a change advisory board (CAB) for ease of discussing security and IT changes to the environment.
The reason I put network diagram on the list is due to cloud environments. Recently I worked with a client that was concerned with the amount of monthly spenditure of their cloud environment. The client was not able to produce an up to date network diagram (yes this includes cloud, web and server infrastructure) this made it alot harder to identify quick configurations such as regions and areas that were enabled that would incorporate potentially higher charges. Although this can be ahcived using open source tools and identifying API calls, in my opinion a diagram would of been far more superior and would of confirmed the responses from the API calls.
How do I fix this …. ? In this particular example the client I was working with was outsourcing their developers, the developers were not cloud experts, this made it difficult to produce a network diagram. We used our responses from the API calls using open source cloud scanners and also using Qualy’s pro we were able to produce a very close diagram to help our client with this issue.
2. Think about your code
We are all familuar with the term “secure code review”. I still see the basics not being done correct, a high proportion of web app tests I conduct and the vulnerabilties I come across could of been avoided if the developers code that was very pretty, functional and useable had been security checked and reviewed, basic XSS and injection is often found due to this error and most compaines only undergo a secure code review usually on a annual basis only to tick the compliance / assurance box, I can assure once a year is not enough!
What to look for …. Think about how your data is being transmitted from point A -> B its absolutley a gold standard that secure HTTPS protocol applied through the web app. Once the transmission code has been thought off how is the data being stored at rest?
Code reviews are also essential in the fact that if required the code meets specific security standards. This also means that the code review should be a complete seperate entity from the group that developed the code, this is to reduce conflict of interest and any bias that may potentially occur.
It goes without saying that code must be properly sanitized. Missing sanitization often leads directly to injection flaws when a user or attacker can inject and execute a custom command in the backend servers.
The list is huge here for potential vulnerabilitites with regards to secure coding but some to be weary of are SQLi, command injection,
LDAP injection, XPath vulnerabilities, NoSQL, Object Relational Mapping (ORM) tool, XML Parsers, and SMTP Headers are the ones I would usually check for upon conducting a secure code review.
When it comes to talking about code, it is probably worth mentioning “boiler plates”, lots of developers will use common web frameworks such as ruby on rails, when fuzzing web applicaitons and coming across common 404 errors common boiler plates and frame works could easily give away the version of framwork being utilised simular to EmberJS which as im sure you know have a default landing page which is often failed or forgotten to be removed within the production environment. Dont use the default boiler plate code! Pay particular attention when using old version of MongoDB !
Some of the tools I would reccomend for static code analysis are;
Checkmarx -> This will cover most languages but is a paid service https://www.checkmarx.com/
PMD -> Java https://pmd.github.io/#home
Bandit -> Python https://pypi.org/project/bandit/
Brakeman -> Ruby https://github.com/github/brakeman
By conducting static code analysis you can often prevent low hanging common vulnerabilities such as;
General XSS by looking for DOM manipulation with innerHTML, Reflected XSS by looking for varibles that are pulled from a URL param, DOM XSS by searching for specific DOM sinks such as “setInterval()”, commons SQLi flaws from searching for user-provider strings being used in queries, commons CSRF by looking for state-changing GET requests, and common DOS vulns by identifying improper written regular expressions.
Let’s not forget dynamic analysis. Static review is usally conducted prior to execution, where as dynamic inspection reviews code post execution. Dynamic code review is usally more expensive and time consuming as it require code execution but very good at filtering out the false postives that static analysis may cause. Some of the tools I like to use when conduting a dynamic review are;
IBM App scan -> https://www.ibm.com/developerworks/library/se-scan/index.html (paid)
Veracode -> https://www.veracode.com/security/code-review (paid)
Iroh -> https://github.com/maierfelix/Iroh (free good for Java)
3. Keys to the Kingdom…. Credentials
Any application that allows users to sign in and make accounts will require credentials, usually in the form of a username and passwords. Some of the main challanges I face working with developers and talking about credentials are the following.
Developers are lazy! If not monitored developers will often give themselves or aquire Admin/Root level access to the application for ovbious reasons. Im not saying developes should not have admin access but for no reason should dev’s be signing in day to day to the appliction using admin privs, ensure the least priv model is applied and followed. I cant stress that point enough, as a web tester, during the recon/info-gathering stage I will spend time trying to identify the companies developer(s) and see if I can take over their accounts due to this reason of usally being dropped into admin if popped.
Does a developer really need access to Github? Github can be an amazing place but as we know it can also be severely dangerous. Just be wary opening up egress/ingress rules for github for developers. It is at least worth having a discusssion at the CAB meeting.
Does the system allow automated attacks? By this I mean, can the attacker guess valid usernames and passwords?
Are you defending against bruteforce attacks? Especially found within wordpress its usually a good idea to enable the wordfence security configurations.
Does the server allow default, weak or well-known passwords? Ensure a strong password/phrase policy is implemented. Password123 doesnt cut it these days.
Application logic, does the application use weak credential recovery (forgot password) methods. Furthermore a consideration around this factor would be, how do we handle the various authourization levels of different users?
Never share user ID’s or session ID’s within the URL.
Be careful not to use plain text and store credentials using an approved hashing algo. Ensure that weak chiphers are removed and updated.
4. Have a monthly security tea break!
I am under the impression that key players in the business who should be involved in security meetings and knowledge simply dont. Stop being reactive and be proactive! Have a good relationship with a cyber security firm that is reputable, allow them to conduct monthly security analysis on your estate. This will cover such activites like monthly automated vulnerability assesments, Anti-virus, Firewall and SIEM alerts, user accounts and generic security information. This allows the outsourced cyber team to monthly monitor, log and inform your company on the risk level of the estate whilst constantly managing the risk level throughout the year as the estate changes.
Furthermore to outsourcing and having a trusted cyber security firm on hand for advice, its often a reasonable idea to sign up to a bug bounty programe such as Hackerone or bugcrowd. This way your website is getting audited lets say on maybe even a daily basis, although these programmes are good and have benefits. I would usually only advise when the basics are done correctly and you have a medium to senior security maturity model.
5. I cant belive i’m going to say it …. MFA!!!
I was hoping 2020 would be the year where I wouldn’t find this issue but nope I will keep praying. Its simple, where possible apply MFA. It should be a gold standard and unless exceptional circumstances arise there is no reason for this security feature not to be configured. When not enabled this usually leads to critical level vulnerabilities being exploited. Google Authenticator is highly regarded for a software based MFA applicaiton. https://www.google-authenticator.com/
6. HTTP Security Headers …..
It is very rare that I come across web applicaitons that have all the basic security headers configured correctly, this just seems madness as its one of the first places a developer should look at. The following headers will at least defend againt the most common low hanging fruit. Pay particular attention to the CSP header.
7. Accounts !
Too many times I come across unused, abandonned user accounts. Think about it most people get anywhere from 20/30 days annual leave to take within the company for that financial year. To this end as a pentester, security manager if you come across accounts that have not been signed into for 3months (90 days) they should be removed. This would usually indicate this employee has left the deparment, company or potentially on long term leave.
Pentesting checklist for Developers and Ethical Hackers
Below I will attempt to provide a high level overview for mutiple catergories predominently around the OWASP top 10 and other commons issues.
Authentication and credentials management:
- Authentication credentials must use TLS and not HTTP cleartext to prevent MITM
- Authentication must be enforced on all pages, except the ones
intended to be public. - The error messages (in the login page, reset password page, and
registration page) should not lead to information-gathering disclosure
(for example, in the case of an invalid username or fuzzed params). - Authentication logic must be validated on the server side.
- Authentication passwords must be saved under secure hashing
algorithms (not MD5 or SHA1), and salting is preferable. - The password’s hashing logic must be on the server side.
- If the application is interacting with third-party web services, you
will need to ensure the authentication as well as these endpoints. - Enforce password complexity/length requirements established by
policy or regulation.
Use the following common best practices:
Minimum length of 12–15 characters
Minimum of one capital letter
Minimum of one special character
Minimum of one number - Ensure that all password fields do not echo the user’s password when
it is entered, and that the password fields have autocomplete
disabled. - Password reset questions should support sufficiently random answers
(for example, What is your favorite color is a bad question because
Red is a very common answer). - If using email-based resets, only send email to a preregistered
address with a temporary random link/password (short expiration
time). Then the password must be re-newed instanly after login. - Enforce account disabling after a number of login failures (five
attempts is a commonly used limit). The account must be disabled for
a period of time sufficient to discourage the brute-force guessing of
credentials, but not so long as to allow for a denial-of-service attack
to be performed. - Reauthenticate users prior to performing critical operations.
- Use multifactor authentication especially on all Admin/Root accounts
- Disable remember me functionality for password fields.
Authorization and access control:
- Authorization must be developed on the server side.
- Deny all access if the application cannot access its security
configuration information (for example, if the application cannot
connect to the database). - Authorization must exist on every web request (for example, the Web
API endpoint). - Access to files (for example, source code, configuration files) and
resources (including protected URLs and web services ) must be
restricted to admins; only they should be allowed to access those
resources. - If authorization data must be stored on the client side, then you must
encrypt it. - Use the Referer header as an additional check, but be careful not to
depend on it because it can be spoofed. - Authorize only HTTP methods: GET, POST, PUT, and DELETE.
Session management
- Sessions must be managed on the server side.
- Session identifier (session ID) must be random (hackers should not be
able to predict it). - Logout functionality should totally terminate your session and should
be available on all the authenticated pages. - Establish a session timeout after inactivity. To calculate the timeout
period properly, you need to calculate the security risk of that
resource. - Do not put session IDs in URLs, logs, and error messages (the session
ID is located in the cookie header). - Set the secure attribute for cookies furthermore Set the HttpOnly attribute for cookies.
Cryptography
- Any cryptographic functionality to protect data should be
implemented on the server side. - Critical data (for example, database-connection strings, passwords,
keys, and so on) must be encrypted and should not be in cleartext. - Cryptographic keys must be protected from unauthorized users (only
super admins should have access to them). - All cryptographic algorithms must use the latest and greatest secure
algorithms. Refer to the NIST organization at https://csrc.nist.gov to
get all the information that you need.
Input validation:
- All data validation must be performed on the server side.
- Encode data before validation.
- All validation failures should be rejected in a custom error message.
- Hazardous characters, such as <>” ‘ % () & + \ /, should be validated.
You should also validate the following:
Null bytes (%00)
New line (\r,\n,%0d,%0a)
dot dot slash (../ or ..\) - Confirm that no hardcoded SQLqueries exist in the source code.
- Truncate all input strings to a reasonable length before passing them
to the copy and concatenation functions.
Output encoding:
- Conduct all the output encoding logic on the server side.
- Sanitize all the output of untrusted data for SQL, XML, LDAP, and operating system commands.
Logging and error handling:
- Use custom error messages and error pages.
- Do not disclose sensitive information in error messages, including
debugging information, such as a stack trace. - Logging controls must be executed on the server side.
- Logging events must be raised on both success and failure actions.
- Make sure that you log the following events:
Validation failures / Authentication attempts / Authorization failures
Tampering events (for example, URLmanipulation for SQL
injection)/ Using invalid or expired sessions / All the administrative functions.
Miscellaneous:
- Make sure that you remove test codes (not intended for production)
before deployment. - Avoid disclosing your unwanted directory structure in the robots.txt
file. Instead, create a parent directory and put all the hidden
directories and files within it rather than disallowing each
directory/file in robots.txt. - Remove any unnecessary information from the HTTP header such as OS versions, web server versions, and programming frameworks.
- Make sure that the following headers exist:
X-frame-options
X-content-type-options
Strict-transport-security
Content-security-policy
X-permitted-cross-domain-policies
X-XSS-protection:1;mode=blockX-content-type-options:nosniff
I hope this gives a good basic insight to common issues found in web apps and how to avoid basic vulnerabilities being exploited. Should developers follow most of these points your business web application will have moderate to high security posture.
