It's not a common question, but I wonder if any tricks or upcoming standards exist.
Belows are a flow and what I want to implement.
Web application loaded from server-side
Client-side script loads some secure contents (not from #1) that need to be protected from web application provider. It could be shown to a user visually.
Web application provider knows where are the secure contents (in Dom path) and possibly may try to catch it by putting a script
However the secure contents shouldn't be hijacked from servers (even from the same origin) or from external application (even from developer tools if possible)
EDIT:
For better understanding, it's for use case where web application doesn't hold user data in their DB but loads the data from somewhere else. In case, I need to protect the data from web application, which is uncommon in regular web application.
You should use a content security policy (CSP) which would enable the browser to deny injection attacks. These can be a little tricky to setup correctly so I would use Report URI to help you get it going. The trick is to use report only mode first until you have validated the settings then switch to enforce.
I wanna write a WAF which detects attacks with signature-based method. for example, for SQL injection, I collect a blacklist contains words such "select", "drop" and etc. when an attacker inputs these strings to query field, then the attack is detected. Now, my question is how to separate these words from valid inputs that a regular user enters (such his username contains "select" word)? (Note that this is a WAF and I don't know what are the fields in the web app to check the best security and write a specific code for every field. I can just check common security and the rest must check by developers of the web app).
There is no use for WAF in regard of SQL injection. Because
There will be too much false positives that will be driving users mad. If such a silly approach were used on this site of Stack Overflow, you were just unable to post your question.
Like any other black-listing based approach it will be always incomplete and thus will not offer 100% protection
There are specific measures to prevent an SQL injection that offer 100% protection
This may be a silly question but is client side application insights safe from spoofing? Microsoft ask you to add a bit of JavaScript to your HTML page that needs recording and part of this contains a hard coded instrumentation key (not a real key below!):
instrumentationKey: "3D486E8C-BDEF-43AB-B27A-9D3F9D42EC14"
There doesn't seem to be any other relationship between Url and key or any mechanism to prevent spoofing of this key client side (i.e. randomly generating the key with different numbers and submitting the page).
This wouldn't cause any damage, but it would be annoying to the receiver of the incorrect monitoring data, which may well be all someone wants to do "because they can".
Have I missed something fundamental as to why this is not possible?
This is absolutely correct that anyone can log misleading or garbage data to anyone’s AI account if they know the instrumentation key. This is also correct for most web other analytics systems: the request to log information is sent unauthenticated and anyone with sufficient skill can emulate a valid user data. The fact that AI has instrumentation key embedded on the page does not make it easier because anyone using web traffic monitor tool like Fiddler can still intercept and emulate the requests, even if instrumentation key was not embedded on the page.
If you suspect that a malicious user will purposefully log misleading data using your AI key, you should use caution and validate if the data makes sense before making your business decisions, for example from how many users was the data obtained and over what period of time, and whether your client-side page view data matches the server-side requests data.
While not exactly a duplicate, i believe the answer is pretty much the same as this one:
How does Google Analytics prevent traffic spoofing
AI doesn't know how or where you're using your key, so how would they know which traffic is legitimate and which is not?
+1 to Alex's answer. FYI, this is the official answer from Azure Monitor: My Instrumentation Key is visible in my web page source
TL;DR:
Yes, data can be skewed but not stolen
It is a common practice
To mitigate the impact, you could set up two separate app insights resources: one for client, the other for server
To overcome the issue, you set up a custom API and forward telemetry data to app insights.
I am architecting a project which uses jQuery to communicate with a single web service hosted inside sharepoint (this point is possibly moot but I include it for background, and to emphasize that session state is not good in a multiple front end environment).
The web services are ASP.Net ASMX services which return a JSON model, which is then mapped to the UI using Knockout. To save the form, the converse is true - JSON model is sent back to the service and persisted.
The client has unveiled a requirement for confidentiality of the data being sent to and from the server:
There is data which should only be sent from the client to the server.
There is data which should only appear in specific views (solvable using ViewModels so not too concerned about this one)
The data should be immune from classic playback attacks.
Short of building proprietary security, what is the best way to secure the web service, and are there any other libraries I should be looking at to assist me - either in JavaScript, or .Net
I'll post this as an answer...for the possibility of points :)...but I don't know that you could easily say there is a "right way" to do this.
The communications sent to the service should of course be https. That limits the man-in-the-middle attack. I always check to see that the sending client's IP is the same as the IP address in the host header. That can be spoofed, but it makes it a bit more annoying :). Also, I timestamp all of my JSON before send on the client, then make sure it's within X seconds on the server. That helps to prevent playback attacks.
Obviously JavaScript is insecure, and you always need to keep that in mind.
Hopefully that gives you a tiny bit of insight. I'm writing a blog post about this pattern I've been using. It could be helpful for you, but it's not done :(. I'll post a link sometime tonight or tomorrow.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm pretty green still when it comes to web programming, I've spent most of my time on client applications. So I'm curious about the common exploits I should fear/test for in my site.
I'm posting the OWASP Top 2007 abbreviated list here so people don't have to look through to another link and in case the source goes down.
Cross Site Scripting (XSS)
XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.
Injection Flaws
Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data.
Malicious File Execution
Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.
Insecure Direct Object Reference
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.
Cross Site Request Forgery (CSRF)
A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.
Information Leakage and Improper Error Handling
Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks.
Broken Authentication and Session Management
Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.
Insecure Cryptographic Storage
Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.
Insecure Communications
Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.
Failure to Restrict URL Access
Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.
The Open Web Application Security Project
-Adam
OWASP keeps a list of the Top 10 web attacks to watch our for, in addition to a ton of other useful security information for web development.
These three are the most important:
Cross Site Request Forgery
Cross Site Scripting
SQL injection
Everyone's going to say "SQL Injection", because it's the scariest-sounding vulnerability and the easiest one to get your head around. Cross-Site Scripting (XSS) is going to come in second place, because it's also easy to understand. "Poor input validation" isn't a vulnerability, but rather an evaluation of a security best practice.
Let's try this from a different perspective. Here are features that, when implemented in a web application, are likely to mess you up:
Dynamic SQL (for instance, UI query builders). By now, you probably know that the only reliably safe way to use SQL in a web app is to use parameterized queries, where you explicitly bind each parameter in the query to a variable. The places where I see web apps most frequently break this rule is when the malicious input isn't an obvious parameter (like a name), but rather a query attribute. An obvious example are the iTunes-like "Smart Playlist" query builders you see on search sites, where things like where-clause operators are passed directly to the backend. Another great rock to turn over are table column sorts, where you'll see things like DESC exposed in HTTP parameters.
File upload. File upload messes people up because file pathnames look suspiciously like URL pathnames, and because web servers make it easy to implement the "download" part just by aiming URLs at directories on the filesystem. 7 out of 10 upload handlers we test allow attackers to access arbitrary files on the server, because the app developers assumed the same permissions were applied to the filesystem "open()" call as are applied to queries.
Password storage. If your application can mail me back my raw password when I lose it, you fail. There's a single safe reliable answer for password storage, which is bcrypt; if you're using PHP, you probably want PHPpass.
Random number generation. A classic attack on web apps: reset another user's password, and, because the app is using the system's "rand()" function, which is not crypto-strong, the password is predictable. This also applies anywhere you're doing cryptography. Which, by the way, you shouldn't be doing: if you're relying on crypto anywhere, you're very likely vulnerable.
Dynamic output. People put too much faith in input validation. Your chances of scrubbing user inputs of all possible metacharacters, especially in the real world, where metacharacters are necessary parts of user input, are low. A much better approach is to have a consistent regime of filtering database outputs and transforming them into HTML entities, like quot, gt, and lt. Rails will do this for you automatically.
Email. Plenty of applications implement some sort of outbound mail capability that enable an attacker to either create an anonymous account, or use no account at all, to send attacker-controlled email to arbitrary email addresses.
Beyond these features, the #1 mistake you are likely to make in your application is to expose a database row ID somewhere, so that user X can see data for user Y simply by changing a number from "5" to "6".
bool UserCredentialsOK(User user)
{
if (user.Name == "modesty")
return false;
else
// perform other checks
}
SQL INJECTION ATTACKS. They are easy to avoid but all too common.
NEVER EVER EVER EVER (did I mention "ever"?) trust user information passed to you from form elements. If your data is not vetted before being passed into other logical layers of your application, you might as well give the keys to your site to a stranger on the street.
You do not mention what platform you are on but if on ASP.NET get a start with good ol' Scott Guthrie and his article "Tip/Trick: Guard Against SQL Injection Attacks".
After that you need to consider what type of data you will permit users to submit into and eventually out of your database. If you permit HTML to be inserted and then later presented you are wide-open for Cross Site Scripting attacks (known as XSS).
Those are the two that come to mind for me, but our very own Jeff Atwood had a good article at Coding Horror with a review of the book "19 Deadly Sins of Software Security".
Most people here have mentioned SQL Injection and XSS, which is kind of correct, but don't be fooled - the most important things you need to worry about as a web developer is INPUT VALIDATION, which is where XSS and SQL Injection stem from.
For instance, if you have a form field that will only ever accept integers, make sure you're implementing something at both the client-side AND the server-side to sanitise the data.
Check and double check any input data especially if it's going to end up in an SQL query. I suggest building an escaper function and wrap it around anything going into a query. For instance:
$query = "SELECT field1, field2 FROM table1 WHERE field1 = '" . myescapefunc($userinput) . "'";
Likewise, if you're going to display any user-inputted information onto a webpage, make sure you've stripped any <script> tags or anything else that might result in Javascript execution (such as onLoad= onMouseOver= etc. attributes on tags).
This is also a short little presentation on security by one of wordpress's core developers.
Security in wordpress
it covers all of the basic security problems in web apps.
The most common are probably database injection attacks and cross-site scripting attacks; mainly because those are the easiest to accomplish (that's likely because those are the ones programmers are laziest about).
You can see even on this site that the most damaging things you'll be looking after involve code injection into your application, so XSS (Cross Site Scripting) and SQL injection (#Patrick's suggestions) are your biggest concerns.
Basically you're going to want to make sure that if your application allows for a user to inject any code whatsoever, it's regulated and tested to be sure that only things you're sure you want to allow (an html link, image, etc) are passed, and nothing else is executed.
SQL Injection. Cross Site Scripting.
Using stored procedures and/or parameterized queries will go a long way in protecting you from sql injection. Also do NOT have your web app access the database as sa or dbo - set a up a standard user account and set the permissions.
AS for XSS (cross site scripting) ASP.NET has some built in protections. The best thing is to filter input using validation controls and Regex.
I'm no expert, but from what I learned so far the golden rule is not to trust any user data (GET, POST, COOKIE). Common attack types and how to save yourself:
SQL Injection Attack: Use prepared queries
Cross Site Scripting: Send no user data to browser without filtering/escaping first. This also includes user data stored in database, which originally came from users.